Once you are experienced enough you'll realize two things, that all programming languages let you solve problems and that programming in itself is not the problem, but rather applying it to solve business requirements is the true problem to solve.
The Hard Thing About Software Development
41–50 of 105 posts
Re: The Hard Thing About Software Development
#42I agree completely. Rarely the hard problems in coding are thinking of a clever algorithm, or solving a particularly nasty scaling problem. Usually I've struggled the most with understanding and building what the customer needs. A spec can be interpreted many different ways and will always have to be polished after its completed. Someone who doesn't know what the customer expects will almost certainly create an imple…
> It makes me think that we're training the wrong people in college by making CS a very difficult, math heavy field which often causes the more human skilled people to drop out. I disagree. I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. It's like suggesting a BS in Physics qualifies somebody to work as an engineer building a satellite…
> I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer.
Completely agree here. I often find myself wondering why 'Software Engineering' isn't the degree required to be a Software Engineer and further doesn't really exist as a major, whereas 'Mechanical Engineering', 'Electrical Engineering', 'Civil Engineering', 'Chemical Engineering', etc. are the degrees associated with those professional titles. To your point, I don't think it's a simple matter of nomenclature (i.e. that CS and Software Engineering are synonymous). Not a CS major myself, but amongst my friends who did their undergrad in the US I don't think they had any classes that covered requirements gathering, putting together schedules, etc. Any CS majors here have a class/classes that covered those topics?
Re: The Hard Thing About Software Development
#43I agree completely. Rarely the hard problems in coding are thinking of a clever algorithm, or solving a particularly nasty scaling problem. Usually I've struggled the most with understanding and building what the customer needs. A spec can be interpreted many different ways and will always have to be polished after its completed. Someone who doesn't know what the customer expects will almost certainly create an imple…
> It makes me think that we're training the wrong people in college by making CS a very difficult, math heavy field which often causes the more human skilled people to drop out. I disagree. I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. It's like suggesting a BS in Physics qualifies somebody to work as an engineer building a satellite…
I'm with you. Even many engineering degrees are more theoretical than people need on the job.
Really, this goes back to the purpose of an undergraduate degree. Some people think they should be job training programs while others think they should teach more fundamental skills / topics so students can learn what they need to know for a job.
In the end, CS is a technical degree about a technical topic. There may be an argument for a less technical CS degree, but CS without mathematical rigor is not CS.
Re: The Hard Thing About Software Development
#44This is a post which touches on a subset of "hard" parts while downplaying other hard parts. I agree that a developer with a deep domain knowledge is precious. In fact, I have seen quite a few developers rising up the hierarchy despite being mediocre on technical skills. The code written by them is big ball of mud but they are good at communicating with stakeholders and understand the business well(And also good at drawing boxes) . This does not mean that there is no cost to it. It is just hidden from others. The memory leak issue, the several bugs introduced due to multiple if-elses encoding the business rules, swallowing exceptions or failing to set right properties for client timeouts. These can exist despite the "deep context" and most of the time junior developers are to be blamed for this because the so-called architect is busy all day in meeting with management.
Also the experience may vary. In my admittedly not so long career(less than a decade) I have seen teams where business rules are the major source of complexity while there are other teams which have less business rules (example the databases/data warehouse/build systems team). Admittedly there are less teams of second type in the world so the general perception is that the hardest part is communication and understanding of business context.
Coming to domain knowledge, even the Mainframe and COBOL chaps make a lot of money while smart open-source contributors freelancing don't. Money is not the only way to judge the hardest problem about software development.
Re: The Hard Thing About Software Development
#45Earlier quoted context omitted.
> It makes me think that we're training the wrong people in college by making CS a very difficult, math heavy field which often causes the more human skilled people to drop out. I disagree. I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. It's like suggesting a BS in Physics qualifies somebody to work as an engineer building a satellite…
> I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. Completely agree here. I often find myself wondering why 'Software Engineering' isn't the degree required to be a Software Engineer and further doesn't really exist as a major, whereas 'Mechanical Engineering', 'Electrical Engineering', 'Civil Engineering', 'Chemical Engineering', etc.…
> Not a CS major myself, but amongst my friends who did their undergrad in the US I don't think they had any classes that covered requirements gathering, putting together schedules, etc. Any CS majors here have a class/classes that covered those topics?
We did this as part of our open ended senior project.
Re: The Hard Thing About Software Development
#46Earlier quoted context omitted.
> I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. Completely agree here. I often find myself wondering why 'Software Engineering' isn't the degree required to be a Software Engineer and further doesn't really exist as a major, whereas 'Mechanical Engineering', 'Electrical Engineering', 'Civil Engineering', 'Chemical Engineering', etc.…
> Not a CS major myself, but amongst my friends who did their undergrad in the US I don't think they had any classes that covered requirements gathering, putting together schedules, etc. Any CS majors here have a class/classes that covered those topics? We did this as part of our open ended senior project.
Interesting, maybe a more informative question for me would be - if you did have a class/classes that covered those topics, did you feel that they prepared you sufficiently for a job as a software engineer? But now I'm starting to sound like an alumni survey... :)
Re: The Hard Thing About Software Development
#47> The nature of the beast is that software requirements rarely change
Put like this, it's hard to agree with the above statement.
Following the spirit of the article, I assume the author means that the problem domain is pretty stable. But I've been in this for more than 20 years, and I know that requirements always change. Not only our understanding, but also the customer/user's understanding of their needs and priorities change.
(Edit: typo)
Re: The Hard Thing About Software Development
#48> The nature of the beast is that software requirements rarely change Put like this, it's hard to agree with the above statement. Following the spirit of the article, I assume the author means that the problem domain is pretty stable. But I've been in this for more than 20 years, and I know that requirements always change. Not only our understanding, but also the customer/user's understanding of their needs and prior…
> Not only our understanding, but also the customer/user's understanding of their needs and priorities change.
And not only does understanding change, but the business requirements actually change too depending on market conditions.
Re: The Hard Thing About Software Development
#49Favorite line "... the software development process is exploratory by nature." I always say the customer/client does not have requirements, they have problems. You will not discover all the requirements until you start solving some of the problems and providing solutions. Only then will they say "oh but...." and drop more requirements on you that they didn't think of up front. Back to that quote. It's not that softwa…
> I always say the customer/client does not have requirements, they have problems.
And those problems change as the business adapts to changing market forces.
Re: The Hard Thing About Software Development
#50Earlier quoted context omitted.
> It makes me think that we're training the wrong people in college by making CS a very difficult, math heavy field which often causes the more human skilled people to drop out. I disagree. I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. It's like suggesting a BS in Physics qualifies somebody to work as an engineer building a satellite…
> I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. Completely agree here. I often find myself wondering why 'Software Engineering' isn't the degree required to be a Software Engineer and further doesn't really exist as a major, whereas 'Mechanical Engineering', 'Electrical Engineering', 'Civil Engineering', 'Chemical Engineering', etc.…
"Software Engineering" does exist as a degree. Or it used to (15 years ago).