3 ms·

Programming is moderately difficult for beginners. Learning the tools, syntax, idioms, libraries... it's a lot to swallow. Programming is nothing compared to

Programming is moderately difficult for beginners. Learning the tools, syntax, idioms, libraries... it's a lot to swallow. Programming is nothing compared to architecture though. Knowing what you want to build, in a way that meets the requirements, is a very time consuming task for all but the simplest of problems. Once you have that, and the aforementioned background in programming, the remaining work isn't very difficult. If someone is doing the architecting for you and defining the work sufficiently, programming isn't hard. It's not easy, but it isn't hard.

pavel_lishin 6y ago
I reject the premise that architecting and programming are two separate fields.
- oriolid 6y ago
  I thought he was writing about designing buildings for a moment.
- 01100011 6y ago
  Many people in our industry never get to do much architecting beyond a very limited scale. Much of my career was spent fixing bugs as a contractor or implementing very targeted features in embedded systems. It was only later on in my career where the balance shifted to more architecting of larger features. Plenty of folks are just 'programmers'. They're barely software 'engineers' and definitely not computer scientists. It is perfectly reasonable to spend your entire career as a programmer, dealing with small issues in a systems you inherited from someone else.
- edejong 6y ago
  I don't think the GP is claiming they are separate fields. However, I would say they are separate modes of thinking and require different skill sets. For example, software architecture around systems design might involve thinking of different layers of responsibility, the sequentiality of development, taking into account the skillsets of the teams and existing technical tools and structures. To me, programming is the art of transforming and ascertaining requirements and principles into executable structure. Architecture is the art of shaping the non-functional requirements and principles. Either by writing them down or by discussing them at a whiteboard, or even by teaching the team about these requirements. Both are like an entangled pair that can be incorporated in one single individual, in different team members or even in different organisational structures. Some architectural decisions can be championed by a random software developer. Some architectural decisions shape companies (AWS). And some architectures should just be thrown out of the window. But, and I am speaking from experience here, as they are different modes of thinking, there should be conscious time and effort for both and they should not be mixed indiscriminately.
nullsense 6y ago
This is very much in the right direction, but to expand on it a little with my 2c... Programming something to produce an expected output is for the most part a very achievable goal when you have no constraints. You can do it however you want, take as long as you want and no-one else will complain how you do it. The more layers of constraints you add in the more challenging it becomes to the point where you could say "programming well" is indeed very challenging and the majority of working devs can't achieve it reliably. I think over time it's a fundamentally impossible task with respect to a certain piece of software because the trifecta of 1) changing industry/aging tech, 2) everyone who contributed to the codebase at a time they didn't understand the system, the domain or programming all that well, and 3) accumulating mistakes in architecture or implementation that you don't have or ever get the budget to fix. So in the end even if you're a stellar dev, you're always working with people who aren't and most likely on a system that is not pristine. Getting a computer to do _something_ is not so hard. Consistently getting the computer to do what you want over time in a way that is easy for your colleagues to grok such that they don't introduce mistakes and also to do it in such a way that's amenable to unforseen future requirements that may or may not arrive? It's ultra challenging. I've learnt to not care so much. Software is an organic thing that will be born, grow, get old and die.

pavel_lishin 6y ago

I reject the premise that architecting and programming are two separate fields.

oriolid 6y ago
I thought he was writing about designing buildings for a moment.
01100011 6y ago
Many people in our industry never get to do much architecting beyond a very limited scale. Much of my career was spent fixing bugs as a contractor or implementing very targeted features in embedded systems. It was only later on in my career where the balance shifted to more architecting of larger features. Plenty of folks are just 'programmers'. They're barely software 'engineers' and definitely not computer scientists. It is perfectly reasonable to spend your entire career as a programmer, dealing with small issues in a systems you inherited from someone else.
edejong 6y ago
I don't think the GP is claiming they are separate fields. However, I would say they are separate modes of thinking and require different skill sets. For example, software architecture around systems design might involve thinking of different layers of responsibility, the sequentiality of development, taking into account the skillsets of the teams and existing technical tools and structures. To me, programming is the art of transforming and ascertaining requirements and principles into executable structure. Architecture is the art of shaping the non-functional requirements and principles. Either by writing them down or by discussing them at a whiteboard, or even by teaching the team about these requirements. Both are like an entangled pair that can be incorporated in one single individual, in different team members or even in different organisational structures. Some architectural decisions can be championed by a random software developer. Some architectural decisions shape companies (AWS). And some architectures should just be thrown out of the window. But, and I am speaking from experience here, as they are different modes of thinking, there should be conscious time and effort for both and they should not be mixed indiscriminately.

nullsense 6y ago

This is very much in the right direction, but to expand on it a little with my 2c... Programming something to produce an expected output is for the most part a very achievable goal when you have no constraints. You can do it however you want, take as long as you want and no-one else will complain how you do it. The more layers of constraints you add in the more challenging it becomes to the point where you could say "programming well" is indeed very challenging and the majority of working devs can't achieve it reliably. I think over time it's a fundamentally impossible task with respect to a certain piece of software because the trifecta of 1) changing industry/aging tech, 2) everyone who contributed to the codebase at a time they didn't understand the system, the domain or programming all that well, and 3) accumulating mistakes in architecture or implementation that you don't have or ever get the budget to fix. So in the end even if you're a stellar dev, you're always working with people who aren't and most likely on a system that is not pristine. Getting a computer to do _something_ is not so hard. Consistently getting the computer to do what you want over time in a way that is easy for your colleagues to grok such that they don't introduce mistakes and also to do it in such a way that's amenable to unforseen future requirements that may or may not arrive? It's ultra challenging. I've learnt to not care so much. Software is an organic thing that will be born, grow, get old and die.