And most of the time thinking about things that should not be done.
Programming Is Mostly Thinking (2014)
51–60 of 339 posts
Re: Programming Is Mostly Thinking (2014)
#52Developers 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."
it's an odd analogy because programs are complex systems and involve interaction between countless of people. With large software projects you don't even know where you want to go or what's going to happen until you work. A large project doesn't fit into some pre-planned algorithm in anyone's head, it's a living thing. diagrams and this kind of planning is mostly a waste of time to be honest. You just need to start t…
Your part of your comment doesn't fit with the rest. With complex projects, you often don't even know exactly what you're building, it doesn't make sense to start coding. You first need to build a conceptual model, discuss it with the interested parties and only then start building. Diagrams are very useful to solidify your design and communicate it to others.
Re: Programming Is Mostly Thinking (2014)
#53A good explanation of this is given on SICP. Ist about solving the problem, not getting the computer to do something.
Re: Programming Is Mostly Thinking (2014)
#54Agree and disagree. Certain programming domains and problems are mostly thinking. Bug fixing is often debugging, reading and comprehension rather than thinking. Shitting out CRUD interfaces after you've done it a few times is not really thinking.
Other posters have it right I think. Fluency with the requisite domains greatly reduces the thinking time of programming.
Re: Programming Is Mostly Thinking (2014)
#55This is why I just don't care about my keyboard, mouse, monitor etc beyond a baseline of minimum comfort.
Typing at an extra 15 wpm won't make a lick of difference in how quickly I produce a product, nor will how often my fingers leave the keyboard or how often I look at the screen. Once I've ingested the problem space and parameters, it all happens in my head.
Re: Programming Is Mostly Thinking (2014)
#56Now with Github Copilot it's even worse/better – whether you like to type or not. Now it's 1) think about the problem, 2) sketch types and functions (leave the body empty), 3) supervise Copilot as it's generating the rest, 4) profit.
Re: Programming Is Mostly Thinking (2014)
#57> how can you experiment with learning on-the-job to create systems where the thinking is optimized? Best optimization is less interruptions as reasearch shows their devastating effect on programming: - 10-15 min to resume work after an interruption - A programmer is likely to get just one uninterrupted 2-hour session in a day - Worst time to interrupt: during edits, searches & comprehension I've been wondering if th…
This is why I work at night 80% of the time. It's absolutely not for everyone, it's not for every case, and the other 20% is coordination with daytime people, but the amount of productivity that comes from good uninterrupted hours long sessions is simply unmatched. Once again, not for everyone, probably not for most.
Re: Programming Is Mostly Thinking (2014)
#58Re: Programming Is Mostly Thinking (2014)
#59Funnily 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…
Sometimes you really wonder where your time went. You can spend 1 hour writing a perfect function and then the rest of the day figuring out why your import does work in dev and not in prod.
I also once butchered the result of 40 hours of work through a loose git history rewrite. I spent a good hour trying different recovery options (to no avail) and then 2 hours typing everything back in from memory. Maybe it turned out even better then before, because all kind of debugging clutter was removed.
Re: Programming Is Mostly Thinking (2014)
#60Programming 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…
And it's a terrible way to make anything, much less software. It's more forgivable when the cost of outer iteration is high because you're making, say, a train, but even then you design around various levels of simulation, iterating in the virtual world. The idea that you can nail down all the requirements and interfaces before you even begin is why so many projects of the type you describe often have huge cost overr…
I see this so often. It's how terrible software is written because people are afraid to change direction or learn anything new mid project.
I rewrite most of my code 2-3 times before I'm done and I'm still 5x faster than anyone else, and significantly higher quality and maintainability as well. People spend twice as long writing the ugliest, hackiest code as they would have to just learn to do it right