The story is good. My experience, however, has been almost the exact opposite. It’s not that 90% is a no-brainer and 10% is fumbling around. It’s that 90% is fumbling around and 10% is no-brainer. In other words, how many people have worked on the same product across companies writing the same code stanzas over and over? Or how many people are solving the same problems project to project? Or if you are, then using the same tech stack/framework you did previously? I find it incredibly hard to estimate something when 90% of the time my honest answer is, “I’ve never built that before”.
The worst part is that the initial requirements are often way closer to something you build before, but "small adjustments" make it into a completely different thing.
I agree 100%. The requirements might sound the same, but only until you dig in.
I've often received the same requirements for a system that already existed, and had to ask, why do you need a new one instead of the one you already have that does exactly what you're asking for? And oh boy does the answer to that get interesting.
The only reason to start a project is because you need something new, otherwise you'd copy an old project. Like teaching school, your students are always the same age even as you get older, it's always new to them, and they make the same mistakes. Engineering projects are eternal September.
I've built the same project many times - when I was in construction building houses. Even when we got a new blueprint it was mostly similar to existing houses and so we could estimate it well - but we always added a little padding to the new print because there were things we would find on the job that we didn't expect. When the print was one we had never built but someone else had we had more confidence in our estimates.
Software though - why would you start over from scratch? That is maybe once every 30 years.
There are a ton of small (software) projects I've started from scratch even though they "look like" the same from afar. The small differences matter. An ex coworker of mine had a saying:
If it "looks like an alligator, except..." then it's not an alligator.
I can't count how many times I got burned, tried to beat previous code into submission to fit the new thing, only to realise I'd have an easier time just doing it bespoke from scratch so that it has 100% fitness for purpose.
That, or you start writing reusable frameworks, which you have to somehow design and maintain, and "the project" becomes the framework itself instead of what you set out to originally do. How many have developed game engines instead of the game they set out to write? or blog generators instead of doing actual blogging they set out to do?
Reusability can be a beautiful trap. I'm done with that, now I just do the damn thing.
This is part of why I don’t understand the argument for vim/emacs.
If you _like_ those then keep using them by all means.
But when people tell me “it’s so much more efficient if you never have to take your hands off the keyboard”, I don’t buy that.
Sure, it is more efficient to know shortcuts for things you do commonly in your IDE. And yeah, editing text is a common task in the IDE.
But (for me) 90% of an engineering task is gathering requirements, testing, waiting for Jenkins or something, chatting with a colleague about the context of the task. Fumbling around.
Writing new code or editing existing code is really a small part of completing the task, and being able to do it as quickly as possible isn’t that big of a benefit (again, for me specifically).
So, again I’ll reiterate, these editors work great for some (I know enough in vi/vim to get stuff done), but don’t try to sell me on the efficiency argument. Just use it because you like it!
The efficiency argument isn't really about macro-efficiency, it's about micro-efficiency. It's not, "with my lightning fast editing speed, I will drop 10k lines today", it's about writing this method faster so I can run tests and see if anything changes, getting me to the next thinking step that much quicker while the problem is still fully loaded into my head. It's about keeping flow state flowing. It's about reducing the iteration time between working code states, so your cycle time gets tightened.
IME, without good muscle memory (touch or hybrid typing) of keys, consciously searching for each key is going to seriously disrupt the flow and thought process behind the code being written.
It may not make you a rockstar programmer, but it will definitely make coding more enjoyable.
I think there was a recent HN discussion on this topic.
10% of my time is 4-8 hours a week. And I'm writing up those requirements, tests, etc. someplace, so I've got hands on keyboard far more than 10% of my time (usually in a vi). Seems like a good opportunity to optimize. I made my choice...not because I 'like it', but because I've been doing it both ways since the 80s and this works.
In the end, tho, you don't understand the argument, don't know the tools (know enough to get stuff done doesn't count), haven't walked in the shoes, but you're absolutely certain all us vi/emacs users are wrong. I mean, I've heard this pissing contest since the Win3 days, so I don't expect much intellectual rigor, but most people who feel the need to "well ackshually" keyboard jockeys at lest take the time to google up something like AskTogs infamous "I spent $50m to prove mice are faster" (for Apple, trying to push the Macintosh, with none of the research ever published AFAIK) to 'prove' how deluded we are. There is actual published research out there covering not just speed but ergonomics and accuracy; it's pretty inconclusive all things considered, and very dependent on the use case the researchers decide to examine, so really easy to cherry pick so you get to win arguments on the internet.
