Everyone knows this who is a programmer. So this article is for other people, like managers?, who don't know how to measure their effectiveness...
Programming Is Mostly Thinking (2014)
91–100 of 339 posts
Re: Programming Is Mostly Thinking (2014)
#92This is a good article to send to non-programmers. Just as programmers need domain knowledge, those who are trying to get something out of programmers need to understand a bit about it. I think I recognise that tiny diffs that I might commit can be the ones that take hours to create because of the debugging or design or learning involved. It's all so easy to be unimpressed by the quantity of output and having somethi…
This. The smallest pieces of code I’ve put out were usually by far the most time consuming, most impactful and most satisfying after you “get it”. One line commits that improve performance by 100x but took days to find, alongside having to explain during syncs why a ticket is not moving.
[deleted]
Re: Programming Is Mostly Thinking (2014)
#93Programming is mostly planning. When you work for companies that take programming seriously (e.g., banks, governments, automotive, medical equipment, etc.), a huge development cycle occurs before a single line of code is written. Here are some key development phases (not all companies use all of them): 1. high level definition, use cases, dependencies; traceability to customer needs; previous correction (aka failures…
> companies that take programming seriously (e.g., banks, governments, automotive, medical equipment, etc.)
(Some) banks (sometimes) hire armies of juniors from Accenture. I wouldn't say they take programming seriously.
My government had some very botched attempts at creating computer systems. They're doing better these days, creating relatively simple systems. But I wouldn't say they're particularly excellent at programming.
Re: Programming Is Mostly Thinking (2014)
#94That's also why it is difficult for me to tell what I've done in the standup meeting on another day. If I tell people I just spend time on "thinking", they will say it is too vague.
Re: Programming Is Mostly Thinking (2014)
#95Developers need to learn how to think algorithmically. I still spend most of my time writing pseudocode and making diagrams (before with pen and paper, now with my iPad). It's the programmers' version of the Abraham Lincoln's quote "Give me six hours to chop down a tree and I will spend the first four sharpening the axe."
I still use pen and paper. Actually as I progress with my career and knowledge I use pen and paper more and digital counterparts less.
It might be me not taking my time to learn Mathematica/Julia tho...
Re: Programming Is Mostly Thinking (2014)
#96[deleted]
Re: Programming Is Mostly Thinking (2014)
#97...and getting stuck.
Re: Programming Is Mostly Thinking (2014)
#98> Sadly, overnight the version control system crashes and they have to recover from the previous day's backup. You have lost an entire day's work.
If I give you the diff, how long will it take you to type the changes back into the code base and recover your six-hours' work?
I accidently deleted about 2 weeks of my work once. I was a junior dev and didn't really understood how svn works :). It took about 2 days to finish the job, but I had no diff and it wasn't 100% ready, so after recreating what I had I still had to spend about a day to finish it.
TL;DR: I think 11/12th is a reasonable estimate.
Re: Programming Is Mostly Thinking (2014)
#99Funnily enough this happened to me. Earlier in my career I had a very intense, productive working day and then blundered a rebase command, deleting all my data. Rewriting took only about 20 minutes. However, like an idiot, I deleted it again, in the exact same way! This time I had the muscle memory for which files to open and where to edit, and the whole diff took about 5 minutes to re-add. On the way out to the car…
In case you didn’t know, doesn’t delete the commit. You can use `git reflog` to find the commits you were recently on and recover your code.
Re: Programming Is Mostly Thinking (2014)
#100I would absolutely agree, for any interesting programming problem. Certainly, the kind of programming I enjoy requires lots of thought and planning. That said, don't underestimate how much boilerplate code is produced. Yet another webshop, yet another forum, yet another customization of that ERP or CRM system. Crank it out, fast and cheap. Maybe that's the difference between "coding" and "programming"?
Implementing known solutions is less thinking and more typing, but on the other hand it feels like CoPilot and so on is changing that. If you have something straightforward to build, you know the broad strokes of how it's going to come together, the actual output of the code is so greatly accelerated now that whatever thinking is left takes a proportionally higher chunk of time.
... and "whatever is left" is the thinking and planning side of things, which even in its diminished role in implementing a known solution, still comes into play every once in a while.