I think that this type of thinking has been very harmful to our industry.
Of course, life is about people. Business is about people. Plumbing is about people.
But what makes software special is code.
And this sentiment leads to horrible conclusions.
If software is about people, not code, who would you expect to manage it better - an engineer whose undergraduate and graduate training was in code, or a business MBA whose training was in people?
If software is about people not code, then who should be prioritized, management who is managing people, or engineers writing code?
This is similar to the Jack Welch mindset of buisiness are more about playing financial games than building great products and it has resulted in the doors blowing off of airplanes in flight.
> If software is about people, not code, who would you expect to manage it better - an engineer whose undergraduate and graduate training was in code, or a business MBA whose training was in people?
Both. The strict separation between tech and humanistic education is the root of (quite) all (modern) evils, and having these two skills in a single person is even better.
Exactly. Technical people building working code that does things that people don't need is just as much a waste as non-technical people knowing what people need but unable to produce code that works. You need both.
So much of the time the foundation is that the software, in its entirety, IS the user interface to the electronics.
It's been that way since the beginning.
Electronics got started much earlier than software and there were physical control panels of various effectiveness too.
Before things deteriorated, it was expected that a UI designer who did not know how to code it their own self, or a coder who was not capable of doing vastly better UI than a non-coder, would not have been suitable for mission-critical situations where living things are expected to interact with electronics.
It all still converges to where you need exactly the same people coding that are designing the UI/UX or it's not going to end up as good as it could be.
"Fortunately" most of the coding and UI out there which are proliferating fastest are not mission-critical.
That would be a nightmare . . .
As a freelancer I have said on several occasions "this won't work". After the 3rd time I would just get on and build it. Every time it was "people will do this and this will happen". But people do stuff wrong in seemingly endless ways. Getting paid for building useless stuff was not a joy.
Yes—this burnt me out on freelance for a long time about a decade ago.
Software is a product and products have users. Well engineered software is open to meaningful modification like other well designed products.
The sentiment expressed in the article is well appreciated by people capable of receiving it and entirely missed by many developers who cannot. While the distinction of people and code is valid it’s not really the problem. The problem is deeper, it’s self orientation versus communal orientation.
A self oriented developer will focus on things like perceptions of easiness and solutions written by strangers. Communal oriented developers will focus more on architecture and documentation because they want the internals of their work to be receptive for other people.
Every developer must go through that phase. You can't do anything useful "for people" if you don't know how to use your tools correctly.
Trying to make jr engineers realize this right away (or treat code as an afterthought) is bound to create terminally junior engineers, or worse - senior engineers that simply can't code.
I have to disagree. For some reason our industry seems to attract a lot of people that are enamored with the tech for tech’s sake. I was one of those. It has a huge epiphany to me at 26 to realize the tech didn’t matter - it was the people (users/customers) and what use they could get out of it. But that realization didn’t change my core - I still loved tech and did deep dives. But now my reason had changed a bit - and what I produced was more usable. I think it’s a very healthy thing to help jr engineers see this.
What I mean is that epiphany you went through is extremely common, and everyone goes through more or less at the same 5-10 years of experience. The difference is the people who didn’t spend that time focusing on technique before becoming seniors tend to be terrible engineers, invariably
Considering the human side and impact of the systems we design and build doesn't preclude knowing the technical stuff. Claiming it will cripple engineers is quite far fetched.
> Claiming it will cripple engineers is quite far fetched.
But the emphasis leads to the MBAs (like McKinsey people) getting into leadership. Then the people who rise are not the people who are great engineers, but people who can play the people games. Look at the effect of the McDonnell Douglas merger on Boeing when the “people” people pushed out the engineering people.
Well yes but actually no. Those MBAs are not your users, so their rise has nothing to do with the software development at its core. Because you're not developing software for your boss(es), remember? You are developing it for some poor humans called users - which may or (more often) may not have a say in this of course.
> cause you're not developing software for your boss(es), remember? You are developing it for some poor humans called users
You're developing for both. It's not a XOR situation.
Almost everything I develop is written with my mum in mind as a user - she's intelligent but not great with computers, if she can use it then almost anyone can.
We have this motto in our company -
More than knowing what to do, we know what not to do - a perk of having donkey's years behind us.
It's about profit margins.
Also, you're people too.
You have to read the code from last week, last month, last year...