Comment by socketcluster
15 hours ago
There are many different ways to write code. The more code there is, the more possible versions of the system could have existed to solve that same set of problems; each with different tradeoffs.
The challenge is writing code in such a way that you end up with a system which solves all the problems it needs to solve in an efficient and intuitive way.
The difference between software engineering and programming is that software engineering is more like a discovery process; you are considering a lot of different requirements and constraints and trying to discover an optimal solution for now and for the foreseeable future... Programming is just churning out code without much regard for how everything fits together. There is little to no planning involved.
I remember at university, one of my math lecturers once said "Software engineering? They're not software engineers, they're programmers."
This is so wrong. IMO, software engineering is the essence of engineering. The complexity is insane and the rules of how to approach problems need to be adapted to different situations. A solution which might be optimal in one situation may be completely inappropriate for a slightly different situation due to a large number of reasons.
When I worked on electronics engineering team projects at university, everyone was saying that writing the microcontroller software was the hardest part. It's the part most teams struggled with, more so than PCB design... Yet software engineers are looked down upon as members of an inferior discipline... Often coerced into accepting the lesser title of 'developer'.
I'm certain there will be AIs which can design optimal PCBs, optimal buildings, optimal mechanical parts, long before we have AI which can design optimal software systems.
Whenever someone gets into Important Reasons why Software Engineering is Different from Programming, I hear a bunch of things that should just be considered “competent programming”.
> Programming is just churning out code without much regard for how everything fits together
What you’re describing is a beginner, not a programmer
> There is little to no planning involved > trying to discover an optimal solution for now and for the foreseeable future
I spend so much time fighting against plans that attempt to take too much into account and are unrealistic about how little is known before implementation. If the most Important Difference is that software engineers like planning, does that mean that being SE makes you less effective?
I disagree with the first point because I worked for quite a few companies on many different projects and less than 10% were doing it even approximately right... And these were all well regarded companies. I even worked for a company backed by YCombinator for over 1 year as a contractor.
I agree that you shouldn't plan too much, but my experience is that anticipating requirements is possible and highly valuable. It doesn't require planning but it requires intuition and an ability to anticipate problems and adhere to certain principles.
For example, in my current job, I noticed a pattern that was common to a lot of tasks early on. It was non-obvious. I implemented a module which everyone on my team ended up using for essentially every task thereafter. It could have been implemented in 100 different ways, it could have been implemented at a later time, but the way I implemented it meant that it saved everyone a huge amount of time since early on in the project.
Also, we didn't have to do any refactoring and were later able to add extra capabilities and implement complex requirement changes to all parts of the code retroactively thanks to this dependency.
One time we learned that we had to calculate the target date/time differently and our requirements engineer was very worried that this would require a large refactoring to all our processes. It didn't; we changed it in one place and didn't have to update even a single downstream process.
It was a relatively complex module which required some understanding of the business domain but it provided exactly the right amount of flexibility. Now, all my team members know how to update the config on their own. We haven't yet encountered a case it couldn't handle easily.
I have similar stories to tell about many companies I worked for. When AI can replace me, it will be able to replace most entrepreneurs and managers.
I think it’s undeniable as an engineering profession when performance and algorithm choice come into play, that or safe control of embedded or industrial devices. There are other contexts where its engineering too, it’s just engineering in the sense that someone designing commodity headphones is doing electronics engineering.