Good evening everyone! This post is an observation upon 3 articles that I chanced to read this week. Links will be posted at the bottom!
Coders and Software Engineers are often seen as robots from the views of non software developing people. They are often described as at the best logical, practical, and thorough. At the worst they are described as weird, creepy, and off-putting. But upon reading these articles something became very clear for me once again. Software Engineers are just people, they are just as faulty as their non programming colleagues, friends, and families. These articles have a common thread in that the progression of software development gets most of its gains from improving the human side of development because humans are the lowest common denominator in the equation. Machines and tools might ocassionally break or fail because of reasons not related to user error but the vast majority of the time actions or results of human error or imperfection are the cause for loss of value when in the process of development. Whether it be a failure to properly plan and design before committing to a large project, handling a merge conflict incorrectly, or properly documenting changes to existing code. The key in the ever increasingly complex world of software design is to create not just good coders or even amazing one. Software is too large and too integrated into every aspect of society. It is rather to equip individuals who have coding skills with the necessary conceptual tools and processes to systematically interact with development projects in such a way that keeps it manageable for the average software engineer to maintain, in a day to day and long term sense. The good software developer is not the fastest coder in the room, the good software developer is the one that creates the best product for the entirety of its lifespan. The fastest coder in the room may be able to get the product on the shelf quickest, however if they lack in other area's they could very easily and are most likely shipping out a product to die a horrible death. And this is because humans are the weak link in the chain during the development cycle. They do things that a computer would never do like get lazy, get tired, call it an early weekend to spend some more time home alone (we all know software developers have no one at home for them), forget to git pull before cranking out a 4 hour stream of consciousnesses coding marathon. This is why a large majority of advancements in software engineering comes from the conceptual side. New strategies, processes, and systems are created to aid every facet of developing outside the actual coding. A way I conceptualize this is to consider an architect who created their own square (the tool) and is using it and a pen to create their blueprints for a house. While they are going on their merry way designing their grand idea, their friend points out to them that their square is not actually a right angle. It is off by 5 degrees when compared to the friend's square. Dismayed but not defeated, the architect asks to borrow their friends so the architect can redraft their plans correctly in time for their proposal. With just enough time to spare the architect is able to rectify their mistake and complete their blueprint for the client. All is well until the client calls up and asks for a third floor in the house with 6 rooms and a pool with a rock facade water slide to be included in the design. The architect accepts the changes, dying on the inside. The architect scraps their original design and starts back at square one. At no point were the tools and methods of design the reason for setbacks. It was the architects failings to make the process less painful for themselves. If they had a more explicit process for ensuring success such as double checking tools and diving into the clients possible wants and needs for a design before beginning the blueprint, the architect would have saved time and heartache. Software development is extremely similar in this regard. A method of approach and an overarching detailed analysis of HOW and WHY to go about coding something is infinitely more important than just coding something. And the best software developers are painfully aware of this.
Articles:
No Silver Bullet
Cherry-Picking and the Scientific Method
Why Google Stores Billions of Lines of Code in a Single Repository