The Hard Thing About Software Development
linkedin.com
The Hard Thing About Software Development
1–10 of 105 posts
Re: The Hard Thing About Software Development
#2I 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 implementation that has these micro problems that make the product miss it's mark.
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. Programming doesn't have to be anymore math heavy than building a house yet we force undergrads to implement algorithms on paper? The amount of wasted potential talent due to college is staggering.
Re: The Hard Thing About Software Development
#3"Being able to program is not the problem. Understanding the problem is the problem" - one of my lecturers in University.
Re: The Hard Thing About Software Development
#4I thought the hard thing in software development was naming things and off by one errors?
Re: The Hard Thing About Software Development
#5I 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…
I think that's an argument for fewer people doing math-oriented CS courses as "training" for being a developer rather than changing the nature of CS courses.
Re: The Hard Thing About Software Development
#6As a lead developer building a platform dealing with the intricacies of union agreements and labor restrictions, this summarizes exactly the thought process that my team has gone through in the last year.
We started with a simple problem that plagues HR departments in every conceivable industry with unions, finding substitute personnel and erroneously assumed that it was a simple fix. Over the past year and a half we have accumulated a great deal of knowledge after interacting with as many people as possible and have finally released a version that meets our original criteria (and much more). It was obviously not a simple fix.
If I have one thing to tell anyone who is looking for business ideas to try out their new programming skills on, I strongly suggest taking the time to learn as much as possible about the people to whom you want to provide a solution, then recruiting one of them to help you build it, lest you become another project that solves a non-issue beautifully.
Re: The Hard Thing About Software Development
#7I thought the hard thing in software development was naming things and off by one errors?
Close. It's cache invalidation and naming things. But I feel ya
Re: The Hard Thing About Software Development
#8I 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…
What's worse is that companies hire that way too. They don't care about your ability communicate or understand a problem from a business perspective. They just care about your ability to write some contrived algorithm on a white board in 30 minutes without asking any clarifying questions.
Re: The Hard Thing About Software Development
#9I 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…
Engineering requires every bit as much requirement gathering and need finding. It probably requires even more up front because physical artifacts are much harder to change.
But I don't see anyone suggesting that we remove math from engineering curriculums because the design programs can do the math for them.
The solution is to train more experts in human computer interaction, the same way we train architects and interior designers to work with civil engineers.