The hardest part of building software is not coding, it’s requirements

by padseekeron 6/26/23, 2:17 PMwith 3 comments
by eschneideron 6/26/23, 2:30 PM

So, so true. As a corollary, one of the best ways of becoming an 10X (or whatever N-X :) developer, is learning to gather and refine requirements. Lots of that is digging into the domain to see how things are supposed to work and working with people to understand how they need things to work. It's rarely as simple as just asking people, you need to be able to go back and forth and help them help you understand.

But yeah, if you can identify and fix potential problems at the requirements phase, you'll save yourself (everybody, really) much future pain.

by rektideon 6/26/23, 3:03 PM

Making software malleable, so that you can iterate & change over time, be responsive to changing needs/wants - is a software superpower.

Regarding AI, I have my doubts buy acknowledge it has remarkable potential for raw output. But how malleable will that output be? Will be make good architectural decisions that allow ongoing adaption & iteration? Will it be able to understand & marshal architecture forward in an intelligent way? I have little evidence yet telling me systems like LLMs are capable of architecting well.

by jleyankon 6/26/23, 3:17 PM

Hmm... I would probably have said "debugging", as that's when you have to deal with coding errors, misunderstandings, ... The design process is critical, but it has always been a flexible, analog process for me. Coding, mostly, is typing - it's the "ok, now we start" aspect of the initial tests and runs that take time and effort.

And if you're not quite sure of where you're going, the code will get worse and the debugging will get longer.