One of the first things beginners in software engineering learn is to dote on their source code. As if getting up to speed with the latest tech stacks & platforms was not challenging enough, the industry (not without reason) places great emphasis on how you code. One hears about phrases like human centric design & testability, and wonders what the problem is if one's software just works.
Why can't the thing just work?
One needs to undergo a mindset shift to realize that code must be written not only to make the end product work, but also to be readable to other developers. That is, of course, if one does not wish to solo their way through the entire project lifecycle (not a great idea for anything long term).
So the idea to internalize is that your source code is also a product. That's the product you use to demonstrate your skills (sell) to your future employers/collaborators, with whom you then collectively sell your software to users. Once you have this mental model set up, it's much easier to make sense of software engineering culture and understand where the vast amount of literature (blog posts, video, podcasts, etc) comes from.
Social trumps all
Human beings tend to get social about the things they do, no matter how technical or mathematical they are. That's called Conway's law or something. Namely that organizations design systems that mirror their own communication structure. What happens if you apply this law to an industry? See what I mean?
People generally also care more about the social aspect of their work than just technical correctness, or even mastery. That's why opinions, conventions and standards start to matter. Developers have tastes and it's easier to work together when those tastes are in tune. That's one reason (among others) why you hear empathy talked about so much in developer circles.
Organizational thinking
There's another important aspect. Any large influential project or organization must necessarily involve many people. While it may naively seem that multiplying effort multiplies output, it takes great foresight & management skills to make one plus one greater than two.
Photo by Austin Distel (@austindistel) on Unsplash
Behaving oneself
Most of the non-programming skills engineers need to master are just that. Project management skills in the context of software. While much of this is commonly learnt like gospel, in a “this is how you do it” sort of way, there's value in sticking to the basics and realizing that professional engineering is a social process, and there are notions of manners. While many of these manners aim to improve productivity / simplify architecture, some of them have idiosyncratic origins. And that's ok. Just important to distinguish them from the technical skills, to understand the motivations behind workflow choices.
Top comments (0)