You often hear this from people who claim it's a revelation. I would say it's a bit overstating the case. Developing software is definitely still about writing code; you can't do it otherwise. But being able to communicate with people well makes your code maybe 100x more useful.
Perhaps there is an opportunity for a more natural language approach to infrastructure as code, but I am not sure how far you can take that since the reality is still a lot of arbitrary delcarations.
Can't you include comments in your code?
Some stuff, like which CIDRs are necessary for which connection, are only obvious in the moment you write it, not 1 or 2 years later or for another person who joins your project next week.
"Hey, just spin up a server with enough capacity, alright?" Yes, sure. Please define capacity.
Those definitions are usually in the docs, which is why the code makes so many references to the docs.
Many infra-as-code systems allow you to add comments to the docs, which (if done well) can really help.
And infra-as-code is much superior to infra-as-let's-click-on-the-gui-until-it-works' Yes, it is hard to read (I know, I do it for a living). But at least you have a document which describes the infra!
“It is very difficult to talk of the operations of the mind with perfect propriety and exactness; because common language has seldom made any very nice distinctions among them, but has generally call’d by the same term all such as nearly resemble each other. And as this is a source almost inevitable of obscurity and confusion in the author; so it may frequently give rise to doubts and objections in the reader, which otherwise he wou’d never have dream’d of.”
––A Treatise of Human Nature, by David Hume, pg. 76
Also this is why I love automation, like scripts for everything. It's like a memo to your future self, with the side benefit of sparing you menial work. I keep even single one liner commands as their own shell scripts with a descriptive name.
Try to read and understand everything your write. If it doesn't click immediately or needs too much outside context or "working memory", make it simpler. Failing that, elaborate in comments.
This is exactly the thinking I see people trapped in and was pointing out. Focused on solving the engineering problems, not the humans that come before and after the problem (both end users and developers). We know there are hard things in engineering and problem solving ain’t easy. I think in an absolute sense you are right, but in a practical sense, it is more than a desirable side effect. Code once written and solving a problem can live on for a very ling time.
Unconscious incompetent - you don’t even know how much you don’t know
Consciously incompetent - you have a rough idea of how much you still have to learn
Consciously competent - with willpower and effort you are competent at your job
Unconsciously competent - you are competent at writing code without effort or even thinking about it
Senior engineers (good ones) become unconsciously competent, and forget how difficult it is to write good code - because it’s now automatic!
I've worked a few times with people I thought were just leadership jockeys their whole career, and then it turns out they were actually software developers for 20 years prior to that. They had all pretty much washed their hands of software, and their attitude was "Well, what would I know now. Not really my scene anymore.". That's a lot of experience thrown out the window.
I spend more time on thesaurus and dictionary sites than I did/do on places like planetsourcecode and stackoverflow.
The thing I see even more with seasoned programmers over time is conscious incompetence. We all start as unconscious incompetence, we all have no idea how much there is to learn, and people tend to assume that you can learn most of what is known in a career or lifetime. Then you learn a lot and grow older, and you find out that the visible bounds of what you don’t know grows much, much faster than the bounds of what you do know. The more you learn and the more you practice, the more you discover how very little you know. (BTW I first heard this from a retiring geophysicist, and have just noticed that it fits every great programmer I’ve worked with, as well as my own experience.)
All tech is magic until you pull the curtain...
A problem that one will only properly learn about by communicating with other humans, understanding their expectations, skillset and most relevant, what their business domain is all about.
I suffer a lot from procrastination and I think one of the reasons is that I find it still a hard to write code. Which most of the time is not coding but reading and trying to understand code. And thinking about all the alternative ways to solve a problem. I often find myself struggling to commit my changes doubting whether my changes are good.
I also still find myself looking up the order of the parameters of standard C library functions that I have used over 30 years. I am dyslectic and struggle to remember facts. I also still find myself making stupid Boolean logic coding errors and make one-off mistakes. I still find myself stepping through loops with the debugger just to see if I did not make a stupid mistake.
It still often takes me more time to solve an issue than I had thought it would take me. There are days when I leave the office feeling that I have accomplished nothing because I have not committed any working code.
If it helps, we're at the dawn of AI assisted development. That will take a lot of the cognitive burden, allowing us to focus on the "what" more than the "how"
I predict AI assisted archicture design will come soon
Bloody shocking just how many layers of concepts, frame works, Etc there is.
Or step away from JavaScript world for a couple of years. About the same sensation.
It was even more of the case in the first 10-20 years this person has been working in programming. Nowadays I've noticed people are getting more socially savvy in software in general, as the prestige of the field develops and more people enter who do it more as a career vs. something of a pure passion.
20/30 years ago you weren't making big bucks and being a programmer (it wasn't called software engineer back then) was associated with basically being on the spectrum, not showering and being a nerd who was low on the socio-sexual status hierarchy. You became a programmer because you liked computers. If you wanted money & prestige you did medicine, law or wall st.
Edit: to clarify, proper variable names, data structures that map onto the real world, function composition that minimizes future faults from developers, ... .
Most popular technique to 'just do the thing' is using 'if my case do #1, else do #2'. Mostly because nobody really understand the business logic. Many reasons, no real one single document with spec, only wikipedia called confluence where you have half truths, barely truths and contradicting each other statements.
In such situation you almost never will understand the logic because there are even no use cases and thus all you can get are regression tests (because there are no use cases list). It gets accumulated over years, many externals / consultants with half-life time 1 year and so continues - chaos in specs (sometimes even transfering from one tool to another one with losing info) and big rotation in companies too dependent on externals.
So instead doing simple if-else, it's better to use wrapper / decorator or even better proxy of chain if more complicated.
It all depends and this textbox is too short to explain the fun facts :-)
We can “what if” all day.. and yes, mentoring can improve these things but that can be said about lots of things that aren’t caused by poor communication. It just really sounds like you need the answer to be poor communication which is why I reacted that way.
Please. This is out of order. You didn’t react to me originally, and nobody here demanded that the answer is communication. You’re the only one insisting. You were asked a simple question, and the (as yet unanswered) question to you was why you attribute problems in production to coding and not communication, since there are plenty of examples of miscommunication leading to production bugs. This ad-hominem nonsense is you just making assumptions.
I can easily agree that you’re sometimes right, that there are some bugs caused by lack of knowledge or skill or schooling, and that there are bugs caused by individuals and that communication plays little to no role. I can also safely say, after a career that spans about the same length as the article author’s, and after doing decades of both programming and management, that the majority of problems that matter in production and the biggest and worst problems I’ve seen were caused by poor communication. One example would be that I’ve twice watched engineering departments decide to rewrite a large codebase from scratch, and it turned into a many year effort costing many millions of dollars, with thousands of production bugs and issues all resulting from the decision that wasn’t well planned. There are of course also bugs that are both, caused by individual knowledge or skill, but could have been saved with more oversight.
Feel free to share some concrete examples if you have some that you feel demonstrate production issues are cause more often by pure code and are not miscommunication. I’ve seen some and I have no doubt there are some. I’m open to hearing your answer and examples. Keep in mind this thread so far from my perspective is text-book miscommunication; the claim that production bugs means code is the cause and communication is not, is so broad and so vague and so ill-defined that of course I have no idea what you really mean. Feel free to elaborate and illustrate your point more clearly.
This is the problem, not that they communicated about it wrong. If your rewrite fails, it's because you either didn't know what you were getting into (scoping issues, happens with a 1-person team too), didn't have enough follow through (again, not unique to teams), or didn't have a gradual transition plan to the new codebase and thus couldn't devote enough bandwidth to it while retaining customers. The failure of these are not related to communication, they're just execution problems. An executive somewhere failed at these companies, not a team.
Hard disagree, this is full of assumption. The teams were complicit in failing to plan well enough. I was there. Expecting an executive to handle this, or placing the blame, sounds like a very bad expectation. Execs can’t plan something like this on their own, they rely on the team to even know what needs rewriting and how to do it and how long it’ll take.
(You still haven’t answered the question.)
Teams are supposed to be complicit; that's why the company hired execs. If you want a company that has no hierarchy, you can always just not hire any executives. "Execs can’t plan something like this on their own" – well yeah, execs can't do anything substantial on their own. If they did, they would cease to be execs.
By question, I'll assume you mean your challenge to provide examples. Well, let's start with the CVEs. How many thousands of those are caused by poor hygiene in the form of buffer overflows? Then there are the crashes that aren't security bugs, like NullPointerExceptions. Actually, the most common security issue is misconfiguration, and there are a few examples here: https://www.insightsforprofessionals.com/it/leadership/famou.... Now, you can probably explain this away by saying any kind of organizational incompetence is a sign of poor communication. You can probably even argue with some validity that poor hygiene is also a result of poor communication, but this is why I am not really here to change minds.
I think of SW engineering as taking some process that’s inherently broken and making it work more often than not. Coding seems more like doing the thing correctly in the first place.
Programmers gets all the shit when others can't communicate, since it isn't until you actually try to write it down into a program that all the missing pieces people failed to communicate upstream start to show up. Programmers jobs wouldn't be hard if other people actually knew how to communicate properly.
The 10x developer is not a myth, it really exists.
What's better, someone who can write as much code as 10 people, or someone who can manage 10 people? Clearly the former.