[{"content":"In his book the \u0026ldquo;The Alliance\u0026rdquo; , Reid Hoffman advises employers to stop thinking of employees as family and free agents, and instead think of them as partners, allies, on a time bounded journey, a tour of duty as he calls it.\nThis insightful view of the relation between employer and employee successfully captures the dynamics of organizations in the age of the unicorn and camel, and no where are those dynamics more clear than the tech industry; a market where the demand for talent is extremely high and the supply of talent is quite the opposite, extremely limited.\nSuch challenge -Along with all the rest of the challenges- requires a new thinking model, one that not only caters for business value but also caters for the individual needs of talents; its not only a matter of finding the right talent to hire, but also a matter of keeping them onboard, continuously challenging them and adding to their lives.\nBut this is easier said than done\u0026hellip; Its complicated, you have to understand that, not one model fits all, after all, us humans when we organize in groups, we tend to create cultures, processes and patterns of communication that are usually unique to that specific group.\nFrom the smallest group, a family, to the bigger ones like companies, religions, countries, ethnicities,\u0026hellip; etc., each group tend to have its own \u0026ldquo;thing(s)\u0026rdquo;, that \u0026ldquo;thing\u0026rdquo; is usually attributed to the different complexities in the surroundings of the group, and this explains why some \u0026ldquo;thing\u0026rdquo; works with some groups and doesn\u0026rsquo;t with another.\nIf we\u0026rsquo;re truly to understand why a group does what it does, and possibly influence them towards something else, or add to their culture, we must first learn the levers available to us, and understand the nature of the environment that made that group what it is.\nThe key is understanding A very popular quote in management is \u0026ldquo;You can\u0026rsquo;t manage/improve/influence what you can\u0026rsquo;t measure\u0026rdquo;, and this statement holds true in several ways. It also applies in the case of forming cultures and organizations that successfully achieves whats expected from them.\nAn organization is but a group of people, aligned towards common goals. The combination of efforts of that group of people amounts to the achievement of the common goals or not. Within the organization, smaller pockets of people exist and work in tandem towards the success of both the individual and the group.\nIt\u0026rsquo;s in that sense that an organization looks exactly like a System, and it only stands to reason that the same principles of systems thinking would apply when designing, structuring and transforming an organization.\nIts all about structure and relations Now double back to \u0026ldquo;The Alliance\u0026rdquo;, what Reid Hoffman and his co-authors describes is a way of reforming the traditional relation and structure of organizations.\nJust like a system, the success or failure of an organization is a function of structure and relations within the organization; organize individuals in an effective structure and build win-win relations between them, and you\u0026rsquo;ve got your self an effective system.\nThis is in no way new, but the radical divergence from the traditional is the individual.\nWe work to live, not live to work Unlike most of human history, today we\u0026rsquo;ve built very effective societies (compared to earlier epochs) that have transformed work from a means to survive, to a means to happiness.\nModern, advanced societies have enabled us to transcend Maslow\u0026rsquo;s Hierarchy of Needs, and start to long for more than just food on the table.\nThis by its own meant that highly skilled workers today consider their place of work quite differently than their counterparts in the early turn of the 20th century.\nA place to realize dreams Given that food and safety have been guaranteed, the place of work today is considered as the place to realize the individual\u0026rsquo;s dreams, whether that be wealth, fulfillment, status, or self-actualisation.\nThis is but a clear observation from the continuous endeavor to achieve work-life balance, something that Rutger Bregman discusses at length in his book \u0026ldquo;Utopia for Realists\u0026rdquo; where he explains how the modern challenge for humanity have shifted from the lack of wealth, to the abundance of wealth but lack of time to enjoy it.\nToday, most of us work to achieve happiness, in one way or another, everyone has their motivations and dreams, and at any point in time believe that their current place of work brings them closer to those dreams.\nSnowflakes With this key learning, we can look at individuals as snowflakes; no one is like the other, each with their aspirations, goals and dreams, and the only way to go about building a truly successful organization is by building the right structure and relation that nurtures those differences.\nThe role of leaders and managers at this point is completely different, no longer is it just about getting things done, or drawing plans and strategies, but its also about building \u0026ldquo;alliances\u0026rdquo; and recognizing the opportunities within the organization that maximizes the profits of those alliances for the business and the individuals.\nAs an employee, your relation with your manager is one of a partnership, you want them to help you realize your dreams and aspirations, to mentor and guide you to your next step.\nIt\u0026rsquo;s only by considering those variables, that we can truly build modern organizations that continue to achieve what was previously thought impossible.\n","permalink":"http://cousine.me/posts/modern-organizations-of-the-21st-century/","summary":"\u003cp\u003eIn his book the \u003ca href=\"http://www.theallianceframework.com\"\u003e \u0026ldquo;The Alliance\u0026rdquo; \u003c/a\u003e, Reid\nHoffman advises employers to stop thinking of employees as family and free\nagents, and instead think of them as partners, allies, on a time bounded\njourney, a tour of duty as he calls it.\u003c/p\u003e\n\u003cp\u003eThis insightful view of the relation between employer and employee successfully\ncaptures the dynamics of organizations in the age of the unicorn and camel, and\nno where are those dynamics more clear than the tech industry; a market where\nthe demand for talent is extremely high and the supply of talent is quite the\nopposite, extremely limited.\u003c/p\u003e","title":"Modern Organizations of the 21st Century"},{"content":"This is a four part article; I\u0026rsquo;ve divided this article into smaller ~4 min posts to make easier to read and follow up:\nPart 1: Anthropology of Time Estimates Part 2: The Nature of Software Part 3: Yin \u0026amp; Yang Part 4: Estimating Software Previously in Part 3: Yin \u0026amp; Yang we\u0026rsquo;ve stared deadlines in the eyes, examined the relation between projects and the passage of time, and we put some scientific labels on various phenomena affecting deadlines and projects.\nIn this part we get to the juicy meat, the actual activity of estimating software development.\nMuch of the ideas are recommended by modern agile frameworks such as SCRUM and Xtreme Programming, they have been tested and proven in battle so I suggest that you give them a try as is before modifying them to meet your team or organisation\u0026rsquo;s needs.\nEstimating Software Two types of problem solving Software engineering is about solving problems through the means of software, so by software estimation we are predicting the effort we need to put in to solve a set of problems (if they are solvable).\nOne of the first things we are trained to do as engineers when solving problems is to break them down into smaller workable problems, this aligns well with our human nature of over-inflating our abilities and competence since it forces us to further examine and analyse the problem at hand before we make a prediction or assumption.\nIn the traditional waterfall model, software problems are usually thoroughly analyse and broken down into very detailed tasks, this allows the implementation team to make a somewhat accurate prediction of the effort needed to implement their solution, however, this method of fully analysing the project has a major pitfall, it fails to account for uncertainty of the future.\nAs we\u0026rsquo;ve observed before, software is subject to many unknowns, which means that change (like always) is inevitable. The waterfall model fails to account for such nature, another shortcoming is relevant to the time and cost incurred in the usually long analysis process, that have been rendered useless as a result of the shifting plane.\nTo account for such nature, the Agile methodology was defined; an incremental and value driven approach to software development in general, the methodology itself is but a mere guideline of how we as engineers and business stakeholders should look at software development as a whole, and as a supplement to those agile principals, frameworks like SCRUM and XP evolved to define a standard operating procedure that significantly improves the life cycle of software development and delivery (DevOps came later to further push delivery to its limits).\nTimebox everything One of the first things you should do is to divide your project into small manageable timeboxes, just like problems, your project\u0026rsquo;s time and schedule also needs to be broken down.\nDividing the schedule makes it easier to estimate what can be done within those short time periods, start by figuring out your Sprint length; a Sprint is the shortest timebox where your team can build and deliver a fully functioning and working piece of software that an end-user can use, depending on the project, your Sprint could vary from 1 to 4 weeks long, just try to keep it within that length (explaining why that 4 month upper limit exists and/or what happens during the Sprint is beyond the scope of this article).\nNext move onto your Releases, a Release can be defined in one of two ways, the first one is to simply take your communicated Deadlines that are probably required by your stakeholders or clients, and simply place a Release on that date (its probably going to be a precise deadline - check Part 3: Yin \u0026amp; Yang for an explanation of the difference between Accuracy and Percission).\nIf you choose to use this first method, then you\u0026rsquo;ll have to play a negotiation game on what scope can fit within in Release, so be prepared to convince and use the Agile Golden Triangle a lot.\nThe second method of defining a Release is to aggregate meaningful problems/solutions together (in SCRUM those are called Epics) and then predict a date where you can expect them to be complete.\nBreak it down Which ever method you choose to timebox your project, its important to break down your problems into smaller ones, that way you can better predict the inherent effort required to solve them.\nBut unlike the Waterfall model, in the Agile methodology we don\u0026rsquo;t break all problems at once, instead we take an incremental approach and break them down by Releases first; the closer we are to a release the more details we have about the problems we are solving in that release:\nThis incremental approach to breaking down your requirements leaves room for the creep of uncertainty in the future, and balances out the time and cost investment into the analysis of the requirements.\nWhile most Agile frameworks recommend that further detailing be done in each Sprint, I recommend that you spend the most time detailing while planning your Release, and only further detailing during a Sprint planning session when needed and required.\nComplexity Now that you have your requirements and problems in a small and workable form, its time to estimate, now you get to be the oracle and predict when those requirements can be fulfilled.\nBut before you play psychic, DON\u0026rsquo;T ESTIMATE IN TIME, remember in Part 1: Anthropology of Time Estimates we observed how we define units and measurements, so its important that we stick to the same approach when we are estimating effort required for an unknown.\nInstead of time, use a relative unit of measurement, so instead of saying \u0026ldquo;This task will take me 10 hours\u0026rdquo;, you should say \u0026ldquo;This task is 2 times harder than that task that took 5 hours\u0026rdquo;, in doing so, you are estimating Complexity, a much more valuable measure of a problem than the time it takes to solve it.\nThe exact way to estimates of complexity is beyond the scope of this series, however I recommend you Google Poker Planning and/or watch Mike Cohen\u0026rsquo;s videos on the subject on Youtube for a nice intro on the subject.\nCapacity and Velocity Once you have your time boxes, and estimates, you can now start measuring capacity and velocity.\nCapacity is the amount of complexity your team is able to deliver, while Velocity is the speed at which your team delivers such complexity.\nBoth measures go in tandem, with Capacity you define how much complexity you can take in a timebox, whether that be a Sprint or Release, and that definition is always based on your team\u0026rsquo;s most recent Velocity measure in the previous timebox.\nThose two measures will continually vary, sometimes they increase, other times they decrease, and plotting those variances on two dimensional graph will give you a nice dataset to conduct regression analysis and define your Undeadline.\n1\nTying everything up By now you should\u0026rsquo;ve learned the limitations we humans inhibit when it comes to predicting the future success/failure of our efforts, the uncertain and ever changing nature of Software in general, the different variables in play when it comes to deadlines and projects, and how you can decrease the variance of your estimates by timeboxing your project\u0026rsquo;s schedule, estimating in complexity and revising your capacity.\nThis series is just scratching the surface of the subject which is a vast field of study that many are consistently trying to improve, so I encourage that you read more on the subject.\nMy reading recommendations are:\nSCRUM: The Art of Doing Twice the Work in Half the Time Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations The Goal: A Process of Ongoing Improvement The Pheonix Project Lean Software Development: An Agile Toolkit Finally I\u0026rsquo;d like to encourage your feedback and questions in the comments section below, I\u0026rsquo;m sure that your feedback will definitely help me and that your questions will definitely help others having the same questions.\nOriginal image by Sewaqu Regression Analysis\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"http://cousine.me/posts/the-art-and-science-of-software-estimation-part-4/","summary":"\u003cp\u003eThis is a four part article; I\u0026rsquo;ve divided this article into smaller ~4 min\nposts to make easier to read and follow up:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/posts/the-art-and-science-of-software-estimation/\"\u003ePart 1: Anthropology of Time\nEstimates\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/posts/the-art-and-science-of-software-estimation-part-2/\"\u003ePart 2: The Nature of\nSoftware\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/posts/the-art-and-science-of-software-estimation-part-3/\"\u003ePart 3: Yin \u0026amp;\nYang\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003ePart 4: Estimating Software\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003cp\u003ePreviously in \u003ca href=\"/posts/the-art-and-science-of-software-estimation-part-3/\"\u003ePart 3: Yin \u0026amp;\nYang\u003c/a\u003e we\u0026rsquo;ve stared\ndeadlines in the eyes, examined the relation between projects and the passage\nof time, and we put some scientific labels on various phenomena affecting\ndeadlines and projects.\u003c/p\u003e","title":"The Art and Science of Software Estimation - Part 4: Estimating Software"},{"content":"This is a four part article; I\u0026rsquo;ve divided this article into smaller ~4 min posts to make easier to read and follow up:\nPart 1: Anthropology of Time Estimates Part 2: The Nature of Software Part 3: Yin \u0026amp; Yang Part 4: Estimating Software In Part 2: The Nature of Software we dove into the nature of software to identify the reasons behind the inherent difficulty in estimating software development.\nIn this post, we look into deadlines and projects, and the science behind both that could greatly improve our skills of predicting the future.\nDeadlines: Yin \u0026amp; Yang If we suck at it, why do we estimate software development at all? Well, one word; Deadlines!\nMost software engineers hate that word -at least in my experience-, it\u0026rsquo;s usually associated with long nights and stressful weekends, but even though most would rather work on their state of the art piece of code without the pressure of time looming over their heads, Deadlines are a necessary evil.\nA necessary evil Deadlines have a very important role, they give us humans a sense of closure and purpose, they align teams and organisations, and they push us to make decisions even when we don\u0026rsquo;t want to.\nYou\u0026rsquo;ve probably worked on that one project left to our own devices, that internal project with no deadline where we just have the Time and Money to perfect everything, you know that project; its the one you ended up scrapping and never published.\nAs bad as they are, we cannot conduct business without deadlines, it would be chaos and if we\u0026rsquo;ve learned something from our own human nature, nothing would be otherwise get done.\nDeadlines can be your friends But what if I told you that Deadlines can exist without the long nights and stressful weekend? The one rule we need to follow is to properly plan.\nSetting deadlines is easy, but sticking to them is hard; as we\u0026rsquo;ve seen in Part 1 we are flawed in measuring effort in relation to time, so simply slapping a deadline on that project is probably not going to work.\nInstead, we should approach setting deadlines with a bit of analysis and planning, and this is where the art comes in, figuring out that balance of time, quality and cost that would yield the most success.\nZen The Golden Triangle The sought after balance is usually represented using the Golden Triangle; a very known figure in project management where each vertex of an equilateral triangle represents one of the three variables affecting the project:\nYou are only allowed to adjust one of the three vertices.\nWith the advent of the Agile methodology, the triangle has been revised to include scope as a variable and quality as an outcome of adjusting the variables:\nBalancing those variables is what most seasoned project managers are after, its an art and a science, and it can make all the difference determining whether a deadline sucks or not.\nAccuracy vs Precision Another distinction we often fail to make, is the distinction between Accuracy and Precision.\nAccuracy is the degree of closeness of a measurement to the true value of the quantity being measured, while Percision is the measure of reliability and consistency of the value being measured.\nIn layman\u0026rsquo;s terms, when we say a value is precise, we are saying that this value is 100% accurate, however, when we say a value is accurate, its expected that we provide a degree of distance from the precise true value.\nGood deadlines are accurate, and rarely precise.\nThe Undeadline No matter what you try, its definitely hard to convince people with ranged deadlines, they will either completely dismiss your arguments, or simply take your later date in the range as the deadline.\nYou might be thinking, what\u0026rsquo;s wrong with having the later date as the deadline? Well remember, we humans have no control over the passage of time, and we fail miserably at predicting that which we don\u0026rsquo;t know, so you\u0026rsquo;d be forgiven if you succumb to our optimistic nature.\nAs we time passes on, given we are hard at work trying to meet the deadline, our certainty increases (remember the four stages pyramid), and now we have a better prediction whether we\u0026rsquo;ll be early to our deadline, meet it, or miss it completely, giving us a shifting line instead of a static one, this line I call the Undeadline.\nThis phenomena can be seen and usually represented by the cone of uncertainty, a nice visualization showing how the variance of the probability that we are correct or mistaken in our assumptions decreases with the passage of time:\nSo early on in our projects, its a mistake to assume we have a Deadline, instead we have an Undeadline that is continuously shifting back and forth until the real deadline reveals it self.\nIn statistics, this process of discovering the real deadline is called regression analysis, and is a very useful tool to ensure that we align expectations as we progress through the project, it encourages transparency and thus trust.\nConclusion We\u0026rsquo;ve observed the nature of deadlines and projects, and how our ability to set deadlines significantly improve as we invest more effort into the project and approach that initial deadline.\nIn Part 4: Estimating Software we talk about the process of estimation and how we can decrease that error variance by following a few simple rules.\n","permalink":"http://cousine.me/posts/the-art-and-science-of-software-estimation-part-3/","summary":"\u003cp\u003eThis is a four part article; I\u0026rsquo;ve divided this article into smaller ~4 min\nposts to make easier to read and follow up:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/posts/the-art-and-science-of-software-estimation/\"\u003ePart 1: Anthropology of Time\nEstimates\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/posts/the-art-and-science-of-software-estimation-part-2/\"\u003ePart 2: The Nature of\nSoftware\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003ePart 3: Yin \u0026amp; Yang\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/posts/the-art-and-science-of-software-estimation-part-4/\"\u003ePart 4: Estimating\nSoftware\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003cp\u003eIn \u003ca href=\"/posts/the-art-and-science-of-software-estimation-part-2/\"\u003ePart 2: The Nature of\nSoftware\u003c/a\u003e we dove\ninto the nature of software to identify the reasons behind the inherent\ndifficulty in estimating software development.\u003c/p\u003e\n\u003cp\u003eIn this post, we look into deadlines and projects, and the science behind both\nthat could greatly improve our skills of predicting the future.\u003c/p\u003e","title":"The Art and Science of Software Estimation - Part 3: Yin \u0026 Yang"},{"content":"This is a four part article; I\u0026rsquo;ve divided this article into smaller ~4 min posts to make easier to read and follow up:\nPart 1: Anthropology of Time Estimates Part 2: The Nature of Software Part 3: Yin \u0026amp; Yang Part 4: Estimating Software In Part 1: Anthropology of Time Estimates we examined how we humans measure values, assess our own competence and experience time.\nIn this post we have a look at why software estimation is hard and why most of our anthropological observations apply to software estimations.\nThe Nature of Software Its Hard! But what does all of that have to do with Software? Let me start by stating a fact; Software development is HARD.\nYes its a cliché, but if you\u0026rsquo;ve had any experience building software, you will probably agree with the statement; there are a lot of unknowns when it comes to software, mostly the human factor is responsible for 90% of those unknowns.\nWe build software for other humans that we have no control over how they\u0026rsquo;d interact with it, not to mention that our software has to account for the physical world from time to time (Mechanical failures, natural disasters, political turmoil,\u0026hellip; etc.).\nTake for example dating (No not that kind of dating 😉), modelling dates and time in software is hard; there are many calendars and methods to measure time that vary in use according to cultures and countries, and from time to time you need to deal with changes such as retiring day-light savings -If you\u0026rsquo;ve been around for more than 25~30 years, you might also remember Y2K and the worries of cyber apocalypse on the day of the new millinea-.\nSoftware too follows Murphy\u0026rsquo;s Law, it needs constant maintenance and enhancement to keep working correctly and efficiently.\nThat factor of uncertainty and obscurity makes software development hard, and is the reason we have techniques like Defensive Programming and Chaos Programming.\nMostly new? One could argue that even though Software Development is hard, our cumulative experience building software eventually makes it predictable and thus measurable, but that\u0026rsquo;s only true if technology slows down.\nAs technology advances, our expectations of what can be done with software grows, and we are faced with newer and harder challenges that we have no idea what kind of effort is needed to overcome.\nThink of the pyramids, at the time of their building it was the pinnacle of engineering, and many would falsely assume that the first pyramid was perfectly built on the first trial, but in fact it took the Pharaohs several trials at smaller less perfect pyramids before they could build the first one, but then what? Expectations grew; each Pharaoh wanted to build a bigger and stronger pyramid than their predecessor, and fast forward today, we are still competing at building the tallest skyscraper or the longest bridge, and every time our ambitions grow, we hit new challenges that were previously unknown to us.\nSame with software, just as the expectations of Pharaohs increased and their aspirations grew with every technological advancement, so does our present expectations grow with every new technological discovery, this makes software an ever changing plane where we constantly face challenges we\u0026rsquo;ve never had experience overcoming before.\nConclusion Software development definitely qualifies as a hard activity to take lightly when estimating, its full of unknown challenges and variables that easily overwhelms our assumptions and predictions.\nIn Part 3: Yin \u0026amp; Yang we take a look at the nature of projects and deadlines, and how we can approach them in a practical and scientific way.\n","permalink":"http://cousine.me/posts/the-art-and-science-of-software-estimation-part-2/","summary":"\u003cp\u003eThis is a four part article; I\u0026rsquo;ve divided this article into smaller ~4 min\nposts to make easier to read and follow up:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"/posts/the-art-and-science-of-software-estimation/\"\u003ePart 1: Anthropology of Time Estimates\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003ePart 2: The Nature of Software\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/posts/the-art-and-science-of-software-estimation-part-3/\"\u003ePart 3: Yin \u0026amp; Yang\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/posts/the-art-and-science-of-software-estimation-part-4/\"\u003ePart 4: Estimating Software\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003cp\u003eIn \u003ca href=\"/posts/the-art-and-science-of-software-estimation/\"\u003ePart 1: Anthropology of Time Estimates\u003c/a\u003e\nwe examined how we humans measure values, assess our own competence and experience\ntime.\u003c/p\u003e\n\u003cp\u003eIn this post we have a look at why software estimation is hard and why most of\nour anthropological observations apply to software estimations.\u003c/p\u003e","title":"The Art and Science of Software Estimation - Part 2: The Nature of Software"},{"content":"This is a four part article; I\u0026rsquo;ve divided this article into smaller ~4 min posts to make easier to read and follow up:\nPart 1: Anthropology of Time Estimates Part 2: The Nature of Software Part 3: Yin \u0026amp; Yang Part 4: Estimating Software Estimating software development is one of the most underrated skills in the Software Engineering industry; we are often more focused on technical competency that we fail to train our estimation muscle causing us to tip the scale to the side of gut feeling and intuition over logical analysis and sound scientific method.\nDon\u0026rsquo;t get me wrong, there is a bit of art when it comes to estimating software development effort and time, however we often think the art is in time and rarely do we consider effort.\nIn this series, I jot down my thoughts on estimating software based on my experience of what works and what often fails.\nAnthropology of time estimates Science measures in relation Its important to study how we humans interact with the universe around us; we exist in time and space, those are our perceivable dimensions and we define our existence and the existence of other matter in relation to those dimensions.\nThink about it, our notion of time is relative to the Earth\u0026rsquo;s rotation around its axis, and its rotation around the sun, a metre is defined by the length of the path travelled by light in vacuum in a three hundredth of a second, and a kilogram is defined relative to Planck constant.\nEvery single measurement we have is defined in relation to a universal constant that we\u0026rsquo;re certain of and have no control over, yet, even with such knowledge we consistently make the mistake of measuring in absolutes, or better yet, predicting unknowns.\nOur ability to measure required effort is flawed when it comes to doing something we have no previous experience doing before; we love giving absolute time as a measure of unknown effort, failing to account for the universal tendency towards entropy, the inherent uncertainty of time.\nInflated sense of competence Another constraint to our abilities is competence; we humans suck at measuring our own competence and mastery! It has been proven again and again that we simply can\u0026rsquo;t fathom the sheer vastness of the universe, and even though we have empirical data to prove it, we rarely account for our incompetence.\nOne of the most popular observations of that limitation is the Dunning-Kruger effect; a cognitive bias where we size our abilities much greater than what they truly are.\nThe effect was first observed in a 1999 study and later confirmed through a subsequent series of studies, however, we\u0026rsquo;ve had other precursors for it long before it was scientifically studied and formalized.\nPrior to the 1999 study by Kruger and Dunning, Martin M. Broadwell, a management trainer, described a model of competency in 1969 and called it \u0026ldquo;The four levels of teaching\u0026rdquo;, over the years many peer-reviewed papers have examined the model and incorporated it into their studies, and it\u0026rsquo;s now known as \u0026ldquo;The Four Stages of Competence\u0026rdquo;1.\nAs our experience and knowledge increases, our ability to make intuitive decisions and assumptions increases, a fact further illustrated by another chart compiled out of the findings by Kruger and Dunning2:\nTime has no king One more anthropological observation is the myth of time control; we often make wrong assumptions about our ability to control the passage of time and how we perceive it.\nAdding together our inflated confidence at competence and our tendency to measure effort in terms of absolute time, we tend to falsely predict output with an increasing error rate as the time frame of prediction increases.\nWe often assume that the further away the date/time, the more control we have over the output and outcome of our efforts, and thus the more optimistic we are about our predictions.\nBut just as we have no control over the vastness of the universe; we cannot create a new universe or stop its expansion, we also cannot create new time, or stop its passage.\nConclusion We\u0026rsquo;ve examined how we humans measure values, assess our own competence and experience time. In Part 2: The Nature of Software we look at the nature of software and why its hard to estimate.\nFour Stages of Competence\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nWhile this chart hasn\u0026rsquo;t been compiled in the original studies, it remains a nice representation of the Dunning-Kruger Effect, and I thought its a good visualization to further explain the ideas in this post.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"http://cousine.me/posts/the-art-and-science-of-software-estimation/","summary":"\u003cp\u003eThis is a four part article; I\u0026rsquo;ve divided this article into smaller ~4 min\nposts to make easier to read and follow up:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePart 1: Anthropology of Time Estimates\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/posts/the-art-and-science-of-software-estimation-part-2/\"\u003ePart 2: The Nature of Software\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/posts/the-art-and-science-of-software-estimation-part-3/\"\u003ePart 3: Yin \u0026amp; Yang\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"/posts/the-art-and-science-of-software-estimation-part-4/\"\u003ePart 4: Estimating Software\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003cp\u003eEstimating software development is one of the most underrated skills in the\nSoftware Engineering industry; we are often more focused on technical\ncompetency that we fail to train our estimation muscle causing us to tip the\nscale to the side of gut feeling and intuition over logical analysis and sound\nscientific method.\u003c/p\u003e","title":"The Art and Science of Software Estimation - Part 1: Anthropology of time estimates"},{"content":"Disclaimer This blog is not neutral; its the reflection of a software engineer on years of software projects as a developer, project manager and sometimes sales person.\nIts my attempt to project Lewis Carroll\u0026rsquo;s Alice\u0026rsquo;s Adventures in Wonderland on my daily experiences dealing with different software projects. In doing so, I\u0026rsquo;ve borrowed lines, scenes and characters from the novel, and I do not claim any ownership or copyright to those.\nSome portions are deliberately exagerated for comical purposes\nIts hard not to notice how similar is software projects management to Lewis Carroll\u0026rsquo;s Alice\u0026rsquo;s Adventures in Wonderland; if you look close enough its full of mythical creatures, mystical worlds and reality bending logic.\nIts a mad tea party! Congratulations Alice! You are cordially invited to a new project.\nMad Hares, Mad Hatters, Cheshire Cats, Dormouse and you poor Alice, its all a mad tea party!\nYou take your place on a long table, listening to the bickering and wallowing of the guests, to your left is the Hare, people call him mad, he wears a nifty vest with a ragged suite on top, a chain drops from his top left vest pocket and it disappears into his lower right pocket where its attached to a fancy pocket watch.\nThe Hare keeps looking at his watch, always mumbling Oh dear! Oh dear! I shall be too late!, the same words already lured you down his rabbit hole and here you are.\nAt the top of the table sits the Hatter, like his friend, people call him mad, and you get to see that first hand!\nAlways switching seats, the Hatter asks unanswerable riddles and blabbers nonsensical remarks; \u0026ldquo;Sure, we can build that space shuttle tomorrow\u0026rdquo;, \u0026ldquo;Guess how many users the Queen wants to serve on launch and design a system that can take it\u0026rdquo;, \u0026ldquo;This feature is critical, in fact all of the features are critical\u0026rdquo; or \u0026ldquo;You need two months to build that? Ok lets build this bigger thing in one month, the Queen demands it\u0026rdquo;.\nFinally, the tired Dormouse, you don\u0026rsquo;t know much about him, he looks tired, he looks like he has been at this party for way too long, and he is always falling asleep, only to wake up violently by the Hare and Hatter.\nHatter always claims you have all the time in the world, after all its always tea time!\nEscaping the madness At the party you think of the peculiar cat, a Cheshire Cat you\u0026rsquo;ve met on your way to the party, and your chat together was intriguing and amusing.\nYou can\u0026rsquo;t wait to go look for Cheshire Cat, so you leave the madness behind and enter the garden of the Queen, you come upon three of the Queen\u0026rsquo;s cards, they are painting white roses blue, the Queen thinks white doesn\u0026rsquo;t really go with anything.\nYou watch as Queen and Hare enter the garden, you meet the Queen, a difficult figure to please. You are invited to a demo of that you do not know, after all the Queen gets what the Queen demands.\nYou\u0026rsquo;re handed a screw driver, \u0026ldquo;Build me a stair where I ascend yet I descend at the same time\u0026rdquo; ordered the Queen.\nHatter, Hare and even Dormouse watch in fear as you try to explain, \u0026ldquo;That\u0026rsquo;s impossible, what you describe is Penrose Stairs, and how can I do this with a screwdriver!\u0026rdquo;.\n\u0026ldquo;Do as you are told\u0026rdquo;, said the Queen, \u0026ldquo;Or off with your head!\u0026rdquo;.\nYou try and try, and lo and behold you\u0026rsquo;ve built a staircase that no one dares use. The Cheshire Cat comes to your aid, with it\u0026rsquo;s logic and wisdom you try your hand at an impossible task.\nThe demo descends into chaos, and the Queen out of patience (not that she had many) orders her executioner to behead the savvy Cat.\nMost everyone\u0026rsquo;s mad here The Cat is now but a floating head laughing with you, or maybe at you, all it enjoys is a creep here and a creep there.\nIts had its fun, for how would an executioner behead a head with no body! Its an impossible feat he argues and complains!\nYou question your sanity, but the Cat says \u0026ldquo;Oh, you can\u0026rsquo;t help that. Most everyone\u0026rsquo;s mad here. [laughs maniacally and begins to disappear] You have noticed that I\u0026rsquo;m not all there myself\u0026rdquo;.\n","permalink":"http://cousine.me/posts/alice-down-the-value-stream/","summary":"\u003cp\u003e\u003cem\u003e\u003cstrong\u003eDisclaimer\u003c/strong\u003e This blog is not neutral; its the reflection of a software engineer\non years of software projects as a developer, project manager and sometimes sales\nperson.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eIts my attempt to project Lewis Carroll\u0026rsquo;s \u003cstrong\u003eAlice\u0026rsquo;s Adventures in Wonderland\u003c/strong\u003e on\nmy daily experiences dealing with different software projects. In doing so, I\u0026rsquo;ve\nborrowed lines, scenes and characters from the novel, and I do not claim any\nownership or copyright to those.\u003c/em\u003e\u003c/p\u003e","title":"Alice Down the Value Stream"},{"content":"The world is becoming more and more noisy, loud and less productive; that\u0026rsquo;s the cost of progress, and in the midst of all that noise, its becoming harder and harder to focus and be productive.\nI consider my self a creative person; I do my best work when I\u0026rsquo;m inspired, excited and focused, so it should be no surprise that I rarely have the chance to be productive with all the daily distractions around us. It also doesn\u0026rsquo;t help that my daily job has shifted from creating to facilitating and enabling, which in part include a lot of distractions, discussions (meetings) and interruptions, basically a creative introvert\u0026rsquo;s worst nightmare!\nTo overcome this I started to seek out practices and create habits, those might sound obvious to you (they certainly sounded obvious to me), tedious or even old news, but they certainly help me a lot to overcome the challenge of staying focused.\nYou should nurture boredom It sounds counter intuitive, the first time I heard that advice I was listening to an audio book (unfortunately I can\u0026rsquo;t remember which 😅), and to be honest, I didn\u0026rsquo;t really give it much thought, but after a few busy weeks I\u0026rsquo;ve found myself lost in details and failing to see the bigger picture.\nWeek in, week out, I hadn\u0026rsquo;t any idea what I needed to do to stay on course with my long term plans whether personally or professionally. I was so deep into daily details that I felt exhausted and uninspired, not to mention a growing sense of no progression towards my objectives.\nThat\u0026rsquo;s when I decided to take some time just to think and actually being bored, my hands however were eager to jot down ideas, objectives, due dates and todos, it just felt like the best way to think and figure out tiny details, not to mention the need for prioritizing and making effort more realistic \u0026amp; visible (I\u0026rsquo;m more of an optimist when it comes to estimating effort).\nWith boredom, I\u0026rsquo;ve managed to reorganize my mind, sort of like defragmenting a hard drive, each and every thought gets archived in its rightful place.\nPlanning ahead It started with just 10 minutes on a Saturday, writing down what I\u0026rsquo;m thinking of for the coming week, just writing down what needs to be done, and maybe elaborating more when I feel a task or idea is unclear and that I\u0026rsquo;d quickly forget what I had in mind for executing it.\nBut what started with 10 minutes, quickly became 30 minutes and now 1 hour each week.\nIt also evolved into a complete system, now I take an hour each week (usually on a Saturday - preferably before the beginning of the week) to write down all the tasks I should attend to during the week, be it personal tasks or professional ones.\nI also quickly found it would be much better if I had them laid out on a weekly calendar, so I found a nice weekly organiser -The amazing dots planner- that lays out the days of the week in small boxes, and made it a goal to fill out the boxes with what needs to be done on each day.\nEach week I\u0026rsquo;d sit down for 30-60 minutes to review the previous week\u0026rsquo;s items, mark what\u0026rsquo;s complete as done, reschedule what I failed to complete, and write down the new week\u0026rsquo;s items.\nFirst I only added bullet points, simply an asterisk (*) at the beginning of the line, and whenever I complete an item I\u0026rsquo;d strike it out. If I\u0026rsquo;ve failed to complete it, then I\u0026rsquo;d strike it out and write next to it the date to which I\u0026rsquo;ve rescheduled it.\nThis however quickly became messy and was hard to read -its equally important to be able to go back and review your performance- so I replaced the asterisk with a box; if I manage to complete the item I\u0026rsquo;d tick the box with a right tick (✔️), if I don\u0026rsquo;t complete it then I\u0026rsquo;d tick it with a cross (❌) and add a p symbol next to it followed by the rescheduled date.\nOne of the important things is not biting more than you can chew, so I make it a rule to only schedule items that I can fit in a single calendar box. Also I try to write items as clear as possible, and as detailed as needed; this makes it so that I can make sure I make full use of both space in the organiser, and my time during the day.\nFor example, I\u0026rsquo;d write complex items on several lines -the more the lines the harder the item-, so if an item takes extra space in the daily box, it means I can\u0026rsquo;t schedule as much items compared to if I had mostly easy items at hand.\nExample; an actual hard task I have coming up next week is writing down reports for 11 startups, I could write this item down as simple as Write down startup reports, but that way it allows me to schedule more items below it, when in fact, that task is extremely time consuming and might need a full day on its own. So what I do is break it down into several items, for each startup I\u0026rsquo;d write Write down X startup report, that way my daily box is filled up and at the same time I can visually see my progress and effort I still have ahead.\nIts not a perfect system yet -and I don\u0026rsquo;t think it will ever be perfect-, but I\u0026rsquo;m going to keep improving on it as I learn more and discover its limitations, and for now its doing its job.\nWhy not digital A question/comment might be Why not use a digital format to do this?, and its a valid one, but here are my two cents; digital formats invite distractions, remember you are now on a platform that has several entertaining outlets to distract you from thinking and organising your thoughts.\nAnother reason why I went with good old pen and paper, is muscle memory and to sway my procrastination habits away (I\u0026rsquo;ll cover that later); when I write things down it just sticks and I feel more confident of what I need to do having written it down.\nSticking to the plan Now comes the hard thing, actually sticking to what you planned, and here is what I\u0026rsquo;ve found:\nYou will get distracted, after all, your days rarely go as planned, and entropy will always get its way and mess up your expectations. Being hard on your self for not sticking to the plan is not productive and can actually make you stop planning all together Killing distractions To address the first finding, you need to identify the distractions, for me I grouped them into two buckets:\nExternal External distractions are those outside your control.\nIts that production incident that you have to attend to with the team, or a frustrated client that you need to deal with, or a team member looking for some help, \u0026hellip; etc., the examples are numerous but they all share one thing in common; its out of your control and you can\u0026rsquo;t really plan for them.\nTo deal with them I quickly asses, if they are urgent then they warrant messing up your plans, otherwise then you can schedule them into your day or week depending on the urgency level, most importantly the number one rule is to say NO, its hard, but its not rude, and others will appreciate it when you say I can\u0026rsquo;t right now, but will do it in an hour, day, or on this date, just make sure you take your organiser out and place that promise where you promised it will be done.\nInternal Unlike external distractions, internal distractions are under your control, its those times when you browsed over to Facebook to check your notifications, or when you got carried away searching for music on Youtube and found yourself watching Funny Cats and Dogs Compilation (literally happened while writing this blog - true story), again the examples are infinite and you probably know what I\u0026rsquo;m talking about.\nUnfortunately, this time you need discipline to deal with those.\nOne form of discipline I\u0026rsquo;ve found effective is the Pomodoro Technique, how it works however is beyond the scope of this post, the gist is, I try to schedule my internal distractions; whenever I feel an urge to check Facebook or surf Cat videos, I just schedule it to a Pomodoro break.\nThe three Rs: Review, Regroup and Reschedule For the second finding, as I mentioned, its not productive being hard on your self when you fail to stick to your plans, so what I advice is the 3 Rs approach™ (😜):\nReview Make a habit of reviewing your days or week while planning the next week, by doing so you learn your daily and weekly capacity, and that helps you planning more accurately in the future.\nRegroup If you screwed up a couple of items, don\u0026rsquo;t sweat it, just try and understand why you failed to complete them; were you too optimistic? Maybe the items were too complex or had a ton of external dependencies, whatever the reasons may be, try and write them down next to the item (if applicable and required).\nReschedule Don\u0026rsquo;t leave incomplete items hanging, simply marking them with a cross (❌) is not enough you also need to reschedule them, even if you are going to schedule them 1 month in the future.\nYou\u0026rsquo;ll rarely go back in your organiser more than a couple of weeks, so if you don\u0026rsquo;t reschedule them right away, chances are, you\u0026rsquo;ll completely forget about those items.\nProcrastination The next hard thing is Procrastination, and to be honest one of my tricks to handle that is the paper and pen, let me explain; I have some OCD tendencies, one of which is messing up nice notebooks/organisers, so when I commit to writing stuff, I want them neat, and if I have a system then I\u0026rsquo;m more inclined not to mess it up.\nSo when I feel the urge to procrastinate, I remember how bad my organiser will look like the next Saturday, and given my OCD/perfectionism tendencies, I commit to completing the item just to avoid messing up my fancy notebook (I think I need to get checked up\u0026hellip;).\nConclusion I\u0026rsquo;m pretty sure I haven\u0026rsquo;t stumbled on a discovery with the habits and exercises I mention here. They are pretty obvious and I\u0026rsquo;m sure I\u0026rsquo;ve picked most of them from books, edutainment and others, but my intention in this post is to highlight the importance of planning and how those seemingly simple and obvious practices, actually help keep you sane and focused in an extremely noisy and messy world.\n","permalink":"http://cousine.me/posts/staying-productive-in-a-noisy-world/","summary":"\u003cp\u003eThe world is becoming more and more noisy, loud and less productive; that\u0026rsquo;s\nthe cost of progress, and in the midst of all that noise, its becoming harder\nand harder to focus and be productive.\u003c/p\u003e\n\u003cp\u003eI consider my self a creative person; I do my best work when I\u0026rsquo;m inspired,\nexcited and focused, so it should be no surprise that I rarely have the chance\nto be productive with all the daily distractions around us. It also doesn\u0026rsquo;t\nhelp that my daily job has shifted from creating to facilitating and enabling,\nwhich in part include a lot of distractions, discussions (meetings) and\ninterruptions, basically a creative introvert\u0026rsquo;s worst nightmare!\u003c/p\u003e","title":"Staying Productive in a Noisy World"},{"content":"I\u0026rsquo;ve been blessed to be part of the learning journey of several software engineers; throughout my career I\u0026rsquo;ve been on both sides of the equation, a student to great engineers who taught me a lot, and a teacher to bright engineers who also taught me a lot.\nGiven I\u0026rsquo;m a fulltime mentor at my current position, I get the same question by every engineer in our team, regardless of their seniority or experience, the one recurring question is always \u0026ldquo;What should I learn next?\u0026rdquo;, some times the variation of \u0026ldquo;I\u0026rsquo;m not sure where my career should go next\u0026rdquo;, or \u0026ldquo;I feel lost/overwhelmed reading/learning to advance my career\u0026rdquo;.\nBut first.. Before I can tackle those kind of questions, I want to stress on something; Your learning and development is your sole responsibility first and foremost.\nYes your employer should have an L\u0026amp;D plan for you, and your manager/lead should be your mentor, but you first need to be a student, and a student is always seeking knowledge and opportunities to learn.\nA good mentor will speed up your learning, put you on the right path, but will not spoon feed you knowledge.\nThey will show you how it should be done, help you do it yourself, let you do it on your own and give you feedback, then finally help you teach it to someone else.\nBut to do that, you have to be thirsty and motivated to learn.\nAre you really looking for a mentor? A mentor doesn\u0026rsquo;t have to be older or absolutely more experienced, their single criteria is that they have something to teach you.\nOften times I\u0026rsquo;ve heard the phrase \u0026ldquo;There is no one around me to learn from\u0026rdquo;, but everytime my reply is \u0026ldquo;There is but you are not looking\u0026rdquo;.\nA mentor can be your peer and/or colleague at work, they can be someone you met on the internet, someone you met in a meetup or conference, but how would you find them if you don\u0026rsquo;t actively seek their help?\nThere is too much to learn In our industry, its a never ending journey of learning, either you are just starting out or well into your tenure as a software engineer, you\u0026rsquo;ll always need to keep learning, that is if you want to remain relevant, and the fact is, there is a lot to learn.\nLike A LOT! its a never ending sea of daily, nay, instantaneously expanding ocean of new techniques, tools, languages, \u0026hellip;, etc.\nYou\u0026rsquo;ll never know it all, and you shouldn\u0026rsquo;t know it all.\nMaster of all = Master of none When you\u0026rsquo;re first starting out, you should aim to build depth and mastery in a single vertical; you are starting out with python? stick with it and learn it properly, build mastery with it, learn the tools and understand the inner-workings, don\u0026rsquo;t make the mistake of spreading yourself too thin, only swiming in the shallows.\nBuilding a mastery is very important because while you think you are learning a single tool, you are actually learning a whole set of fundamentals, first of which is how to learn in the first place. You are finding your own style of learning, and that is one skill that once you master, you\u0026rsquo;ll propel your L\u0026amp;D quite the distance forward.\nBeing a master in a vertical allows you to spread your wings into other verticals smoothly because it gives you the ability of building patterns and relations; you learned Python pretty well, bet now you can go into Ruby and perfectly understand the syntax, you even know what duck typing is, garbage collection, closure, \u0026hellip; etc. its more or less the same concepts and fundamentals just different sugar here and there, and its those differences that you need to understand, no longer the whole set of fundamentals.\nSpreading your wings Once you\u0026rsquo;ve a mastery, its time to spread your wings, you need to start expanding your horizon, don\u0026rsquo;t fear trying new things, taking on new challenges, but don\u0026rsquo;t forget You\u0026rsquo;ll never know it all.\nI\u0026rsquo;ve never met a good engineer who knows everything, in fact most of them rely heavily on studying, stackoverflow and google, but you know what their real secret is? They know what to study and what to look for, thats it, they don\u0026rsquo;t have it memorized by heart but they know it exists and what its limitations and capabilties are.\nConclusion It\u0026rsquo;s perfectly fine that you feel lost in the vast sea of tech, but the most important thing is how you learn to swim and how you ask for help.\nJust remember its not a race, its a marathon, and the only competition you have is your past self.\n","permalink":"http://cousine.me/posts/on-engineering-learning/","summary":"\u003cp\u003eI\u0026rsquo;ve been blessed to be part of the learning journey of several software engineers;\nthroughout my career I\u0026rsquo;ve been on both sides of the equation, a student to great\nengineers who taught me a lot, and a teacher to bright engineers who also taught\nme a lot.\u003c/p\u003e\n\u003cp\u003eGiven I\u0026rsquo;m a fulltime mentor at my current position, I get the same question by\nevery engineer in our team, regardless of their seniority or experience, the one\nrecurring question is always \u0026ldquo;What should I learn next?\u0026rdquo;, some times the variation\nof \u0026ldquo;I\u0026rsquo;m not sure where my career should go next\u0026rdquo;, or \u0026ldquo;I feel lost/overwhelmed reading/learning\nto advance my career\u0026rdquo;.\u003c/p\u003e","title":"On Engineering Learning"},{"content":"Lets set things straight the software engineering landscape in Egypt has been suffering for the past few years; since 2014 we\u0026rsquo;ve been losing more and more talents to Europe for a number of reasons (that we won\u0026rsquo;t go over now), this so called brain drain has created a new phenomena, and please bare with me, a huge number of unqualified \u0026ldquo;seniors\u0026rdquo;.\nI usually don\u0026rsquo;t like to write about the local field; I often feel its futile to talk and prefer tangible actions, however, I\u0026rsquo;ve been provoked by the number of uninformed posts and job descriptions circulating social networks, so here goes 😰.\nIn this post I will try to objectively explain why I think most local seniors in the field right now are really mid-intermediate at best, I also want to point out that I am making this judgement without taking the soft-skills side of the job into consideration, in other words, this is purely a technical assessment.\nDefining a Senior I don\u0026rsquo;t consider \u0026ldquo;miles under their belt\u0026rdquo; a proper measurement of someone\u0026rsquo;s level, you might have been coding for 20 years but that doesn\u0026rsquo;t make you a senior; what makes you a senior is the diversity of your experiences during those 20 years.\nTo get you on my same page, here is what I think makes a good senior:\nAbility to take on complex tasks and run with them from start to end with minimum supervision Ability to write flawless code following conventions and best practices Knowledge of the underlaying technology they are using day-in day-out Ability to go off-text when faced with a problem that can\u0026rsquo;t be fixed using their stack of choice Deep knowledge of the SDLC Deep knowledge of standards Fast learner Why you are not a Senior Now that we have the Senior criteria defined, here is why most are not seniors:\nYou use framework \u0026ldquo;X\u0026rdquo; written in \u0026ldquo;Y\u0026rdquo; but don\u0026rsquo;t know how to use language \u0026ldquo;Y\u0026rdquo; I often meet a lot of people who are very proficient using a certain framework, but when it comes to writing code in the underlaying language powering that framework, they often have trouble structuring their code and fail to use the construct provided to them by the language.\nA senior must know their language cover to cover, they should be very experienced in what their language offers. I could even go as far as requiring that they know how their compiler or virtual machine handles their code.\nYou flow behind hypes without understanding the technology Many times you find teams using new hyped technologies without really understanding the problem they solve, probably the best example to that is the NoSQL hype train a couple of years ago, which still continues to this day to some extent.\nA senior is able to judge whether a new technology solves the problem they are working on or not, they also know the limitations of that new technology and how it works.\nYour code is full of vulnerabilities If you are not able to identify vulnerabilities in your code then sorry, you are not a senior.\nYou have been coding using stack \u0026ldquo;X\u0026rdquo; for 10 years Using \u0026ldquo;X\u0026rdquo; for 10 years doesn\u0026rsquo;t make you a senior in the field, it makes you an expert in \u0026ldquo;X\u0026rdquo;.\nOur field moves quickly and if you are staying put with your knowledge you will quickly become obsolete; think early 2000s .NET moocs and MS certifications, Oracle JEE certifications, \u0026hellip; etc., if you are not light on your toes, continuously learning your years of experience simply makes you an \u0026ldquo;expert\u0026rdquo; but not a senior.\nYou can\u0026rsquo;t recognize good code from bad code 5 nest loops is all I have to say about this one.\nWhat should you do My intention with this post is not to criticize or demotivate, but to bring a problem into the spotlight, we need to invest more into ourselves before climbing the ladder of seniority, its not the years that contribute to your career, its what you do with those years.\nI strongly encourage you to broaden your horizon, to read more, to learn more, and to innovate instead of blindly following hypes. I understand that abstraction is part of our everyday, but this doesn\u0026rsquo;t mean that you should stop learning about how things work.\n","permalink":"http://cousine.me/posts/you-are-not-a-senior/","summary":"\u003cp\u003eLets set things straight the software engineering landscape in Egypt has been\nsuffering for the past few years; since 2014 we\u0026rsquo;ve been losing more and more\ntalents to Europe for a number of reasons (that we won\u0026rsquo;t go over now), this so\ncalled brain drain has created a new phenomena, and please bare with me, a huge\nnumber of unqualified \u003cstrong\u003e\u0026ldquo;seniors\u0026rdquo;\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eI usually don\u0026rsquo;t like to write about the local field; I often feel its futile to\ntalk and prefer tangible actions, however, I\u0026rsquo;ve been provoked by the number of\nuninformed posts and job descriptions circulating social networks, so here goes 😰.\u003c/p\u003e","title":"You Are Not a Senior"},{"content":" ![or Sep 24 2015, close enough!](https://media.giphy.com/media/o2VCZtdSm3i1O/giphy.gif) Hey there! it\u0026rsquo;s been 3 years since I last wrote anything here, it\u0026rsquo;s also been a year since I even had a site!\nI initially wanted to try and salvage my older posts which got deleted after I failed to pay my due server bills (procrastnation much 😇), but afte rgoing back in time (check the gif above ☝️), specifically to September 24th, 2015, I decided not to import anything and to just start fresh.\nSo welcome to my geek space, be sure to stick around (I do write stuff) and before you go, click that speaker icon on the right side under my avatar.\nTell you what, click this one .\n","permalink":"http://cousine.me/posts/we_are_back/","summary":"\u003ccenter\u003e\n![or Sep 24 2015, close enough!](https://media.giphy.com/media/o2VCZtdSm3i1O/giphy.gif)\n\u003c/center\u003e\n\u003cp\u003eHey there! it\u0026rsquo;s been 3 years since I last wrote anything here, it\u0026rsquo;s also been\na year since I even had a site!\u003c/p\u003e\n\u003cp\u003eI initially wanted to try and salvage my older posts which got deleted after I\nfailed to pay my due server bills (procrastnation much 😇), but afte rgoing back\nin time (check the gif above ☝️), specifically to \u003ca href=\"https://web.archive.org/web/20170924103000/http://cousine.me:80/\"\u003eSeptember 24th, 2015\u003c/a\u003e,\nI decided not to import anything and to just start fresh.\u003c/p\u003e","title":"Aaaand We're back!"},{"content":"As software engineers, we can\u0026rsquo;t afford to stop learning; our craft and career is a continuous learning journey.\nThis is why I\u0026rsquo;ve opted to keep a list of the books, articles and podcasts I\u0026rsquo;ve read and/or want to read next so as to help inspire other engineers as I\u0026rsquo;ve been inspired.\nI will keep this list as updated as possible, and I welcome your suggestions for adding other titles to the list.\nMy bookshelf Omar's favorite books » Share book reviews and ratings with Omar, and even join a book club on Goodreads. \u0026lt;/div\u0026gt; \u0026lt;script src=\u0026quot;https://www.goodreads.com/review/grid_widget/7673536.My%20bookshelf?cover_size=medium\u0026amp;hide_link=\u0026amp;hide_title=\u0026amp;num_books=20\u0026amp;order=a\u0026amp;shelf=read\u0026amp;sort=date_added\u0026amp;widget_id=1626866569\u0026quot; type=\u0026quot;text/javascript\u0026quot; charset=\u0026quot;utf-8\u0026quot;\u0026gt;\u0026lt;/script\u0026gt; Podcasts Software Engineering Daily Coding Blocks Elixir Mix Data Skeptic ","permalink":"http://cousine.me/books/","summary":"\u003cp\u003eAs software engineers, we can\u0026rsquo;t afford to stop learning; our craft and career is\na continuous learning journey.\u003c/p\u003e\n\u003cp\u003eThis is why I\u0026rsquo;ve opted to keep a list of the books, articles and podcasts I\u0026rsquo;ve\nread and/or want to read next so as to help inspire other engineers as I\u0026rsquo;ve been\ninspired.\u003c/p\u003e\n\u003cp\u003eI will keep this list as updated as possible, and I welcome your suggestions for\nadding other titles to the list.\u003c/p\u003e","title":"My current reading list"},{"content":"\nAbout me I\u0026rsquo;ve been a coder since I was 10 years old, went through the rise \u0026amp; fall of Microsoft Developer hype. Worked with C/C++, VB, C#, PHP, Java, and found my self in Ruby \u0026amp; Rails for a long time before adding Go and Elixir to my toolbox.\nEnterpreneured a company called mash for 8 years, working day in day out with fellow engineers on fun and interesting products, then moved into mentoring and guiding fresh engineers through their career journey.\nTaught career shifters to code in bootcamps and proud to have been part of 80 ambitious people\u0026rsquo;s journey shifting their careers into programing.\nLinux user and strong believer in Open Source \u0026lt;3.\nDirector of Engineering @Swvl, #1BillionBookings!\n","permalink":"http://cousine.me/about/","summary":"\u003cp\u003e\u003cimg alt=\"workspace\" loading=\"lazy\" src=\"/desk.jpg\"\u003e\u003c/p\u003e\n\u003ch3 id=\"about-me\"\u003eAbout me\u003c/h3\u003e\n\u003cp\u003eI\u0026rsquo;ve been a coder since I was 10 years old, went through the rise \u0026amp; fall of\nMicrosoft Developer hype. Worked with C/C++, VB, C#, PHP, Java, and found my\nself in Ruby \u0026amp; Rails for a long time before adding Go and Elixir to my toolbox.\u003c/p\u003e\n\u003cp\u003eEnterpreneured a company called mash for 8 years, working day in day out with\nfellow engineers on fun and interesting products, then moved into mentoring and\nguiding fresh engineers through their career journey.\u003c/p\u003e","title":"This is where I rant!"}]