They are the reason everything is complex and fragile.
"Easy, let the use edit this config file"
"Just create a docker-compose file with this content"
"Just put the package directory here and the templates directory there"
Death by a thousand cuts. Every cut is just a tiny "just do that" kinda statement.
The result is that to get anything working you have to remember a 100 tiny annoying details with no feedback mechanism to tell you whether you got everything right or forgot something critical.
This is why most programming jobs suck the soul right out of you.
I like the quote, “If you want someone to do something, make it easy for them to do it.”
That seems obvious, but it could press the first type of engineer to think about “them”. That is, who is going to do the thing, and what do they know? Maybe they’re not a programmer who understands the internal model of the system. Maybe they’re someone in a hurry, who is actually trying to do some other job, but needs to use the system to do one part of the job.
Everybody should assume their customer isn’t going to read the manual. All the customers are used to the magic of google where you type something in and get a whole bunch of help in the blink of an eye.
Good theory and it seems true to me, though probably there a are dozen other archetypes we can derive out of those two. In general there seems to be at least the solution-centric engineer and the people-centric engineers. Being myself someone in the second group I can see how if you only have the later in a group you may end with over complex solutions while in the first you may end up with weak solutions. As everything in life a balance is what we should strive for. (But honestly I prefer a balance inclined towards the later.
Cool theory. I tend to be type 1 when I'm just wondering or thinking out loud about possible solutions, but type 2 rapidly gets in the way, and usually wins the fight :D
There are of course many more types of software engineers, but this is a distinction I recognise. In another industries where qualifications matter type 1 would not be classed as engineers at all, its more like a comparison between DIY hobbyists and battle hardened engineers. Ironically non tech leadership often values the attributes of Type 1 since they appear to engender a 'go get em' attitude. So the industry actively promotes such attitude amplifying complexity at all levels.
I have found myself reading this article for the third time. I am currently working on a project and I had to consider users who don't want to create account but use the service yes things got messy but I had give email status alert on their orders. In the near future I will introduce order status check with order ID. Yes it is a lot of work but I also much enjoy websites and apps that I have to use without creating an account while having access to the core functionalities.
These are subtypes of the New Jersey approach, right? “Easy, just fail with EINTR” and “Hard, we have to make every luser put a loop on every syscall”.
So you’re missing the other top-level type of engineer, who sees a hard technical problem because it’s assumed that one would never choose a solution which required such concessions from users in the first place.
I think most developers are that type 1. They are the RTFM type and highly logical people. Type 2 uses more common sense. Type 2 is future engineering leadership.
This whole post said more about the management than the worker.
The person who was suppose to care about the process glazes over it, while the people expected to act or provide the solutions see the full picture of issues that in addition need to be thought of as well.
This speaks volumes to how broken the process of the life cycle of that development workflow is.
The first type is very common.
They are the reason everything is complex and fragile.
"Easy, let the use edit this config file"
"Just create a docker-compose file with this content"
"Just put the package directory here and the templates directory there"
Death by a thousand cuts. Every cut is just a tiny "just do that" kinda statement.
The result is that to get anything working you have to remember a 100 tiny annoying details with no feedback mechanism to tell you whether you got everything right or forgot something critical.
This is why most programming jobs suck the soul right out of you.
I like the quote, “If you want someone to do something, make it easy for them to do it.”
That seems obvious, but it could press the first type of engineer to think about “them”. That is, who is going to do the thing, and what do they know? Maybe they’re not a programmer who understands the internal model of the system. Maybe they’re someone in a hurry, who is actually trying to do some other job, but needs to use the system to do one part of the job.
Everybody should assume their customer isn’t going to read the manual. All the customers are used to the magic of google where you type something in and get a whole bunch of help in the blink of an eye.
"yeah, but what if the guy in The Martian didn't have to build this stuff for himself but for others?"
Fortunately, we do have another novel exploring EXACTLY that hypothetical (https://www.fimfiction.net/story/396744/the-maretian).
Good theory and it seems true to me, though probably there a are dozen other archetypes we can derive out of those two. In general there seems to be at least the solution-centric engineer and the people-centric engineers. Being myself someone in the second group I can see how if you only have the later in a group you may end with over complex solutions while in the first you may end up with weak solutions. As everything in life a balance is what we should strive for. (But honestly I prefer a balance inclined towards the later.
Cool theory. I tend to be type 1 when I'm just wondering or thinking out loud about possible solutions, but type 2 rapidly gets in the way, and usually wins the fight :D
There are of course many more types of software engineers, but this is a distinction I recognise. In another industries where qualifications matter type 1 would not be classed as engineers at all, its more like a comparison between DIY hobbyists and battle hardened engineers. Ironically non tech leadership often values the attributes of Type 1 since they appear to engender a 'go get em' attitude. So the industry actively promotes such attitude amplifying complexity at all levels.
I have found myself reading this article for the third time. I am currently working on a project and I had to consider users who don't want to create account but use the service yes things got messy but I had give email status alert on their orders. In the near future I will introduce order status check with order ID. Yes it is a lot of work but I also much enjoy websites and apps that I have to use without creating an account while having access to the core functionalities.
These are subtypes of the New Jersey approach, right? “Easy, just fail with EINTR” and “Hard, we have to make every luser put a loop on every syscall”.
So you’re missing the other top-level type of engineer, who sees a hard technical problem because it’s assumed that one would never choose a solution which required such concessions from users in the first place.
I think most developers are that type 1. They are the RTFM type and highly logical people. Type 2 uses more common sense. Type 2 is future engineering leadership.
Has someone found layer 8?
Emoji should never have been put into unicode, but they were and now we have to deal with a pile of poo.
There's also two types of mangers too.
There is the: "we are going to solve X"
And the: "You need to solve X"
This whole post said more about the management than the worker.
The person who was suppose to care about the process glazes over it, while the people expected to act or provide the solutions see the full picture of issues that in addition need to be thought of as well.
This speaks volumes to how broken the process of the life cycle of that development workflow is.
This is a false dichotomy