I liked "Code is just the residue of the work"
Programming Is Mostly Thinking (2014)
21–30 of 339 posts
Re: Programming Is Mostly Thinking (2014)
#22Wait… you have the diffs… why are you retyping the lost code by hand? What am I missing?
They specifically mentioned the diffs being physically printed, like, on paper. Also, it’s just a convoluted example to highlight the core idea.
Re: Programming Is Mostly Thinking (2014)
#23I'm confident enough to tout this number as effectively true, though I should mention that no company I work with has so far been willing to delete a whole day's work to prove or disprove this experiment yet. Long ago when I was much more tolerant, I had a boss that would review all code changes every night and delete anything he didn't like. This same boss also believed that version control was overcomplicated and d…
Was your work better or worse second time around?
Re: Programming Is Mostly Thinking (2014)
#24This is laid out pretty early on by Bjourne in his PPP book[0], > We do not assume that you — our reader — want to become a professional programmer and spend the rest of your working life writing code. Even the best programmers — especially the best programmers — spend most of their time not writing code. Understanding problems takes serious time and often requires significant intellectual effort. That intellectual c…
The hardest part is finding out what _not_ to code, either before (design) or after (learn from prototype or the previous iteration) having written some.
No code is faster than no code!
Re: Programming Is Mostly Thinking (2014)
#25I'm confident enough to tout this number as effectively true, though I should mention that no company I work with has so far been willing to delete a whole day's work to prove or disprove this experiment yet. Long ago when I was much more tolerant, I had a boss that would review all code changes every night and delete anything he didn't like. This same boss also believed that version control was overcomplicated and d…
I don't have a big sample size, but 2/2 of my first embedded jobs both used network shares and copy+paste to version their code. Because I had kind-of PTSD from the first job, I right off asked the boss on the second job if they had a git repository somewhere. He thought that git is the same as Github and told me they don't want their code to be public.
When they were bought of by some bigger company, we got access to their intranet. I digged through that and found a gitlab instance. So then I just versioned my own code (which I was working on mostly on my own), documented all of it on there, even installed a gitlab runner and had a step-by-step documentary on how to get my code working. When they kicked me out (because I was kind of an asshole, I assume), they asked me to hand over my code. I showed them all of what I did and told them how to reproduce it. After that the boss was kinda impressed and thanked me for my work. Maybe I had a little positive impact on a shitty job by being an asshole and doing stuff the way that I thought would be the right way to do it.
Edit: Oh, before I found that gitlab instance I just initialized raw git repositories on their network share and pushed everything to that
Re: Programming Is Mostly Thinking (2014)
#26Who hasn't accidentally thrown away a days worth of work with the wrong rm or git command? It is indeed significantly quicker to recreate a piece of work and usually the code quality improves for me.
Re: Programming Is Mostly Thinking (2014)
#27I 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"?
> Maybe that's the difference between "coding" and "programming"?
I know I'm not alone in using these terms to distinguish between each mode of my own work. There is overlap, but coding is typing, remembering names, syntax, etc. whereas programming is design or "mostly thinking".
Re: Programming Is Mostly Thinking (2014)
#28Who hasn't accidentally thrown away a days worth of work with the wrong rm or git command? It is indeed significantly quicker to recreate a piece of work and usually the code quality improves for me.
I’ve often found it alarming to see how much better the re-do is. I wonder whether I should re-write more code.
Re: Programming Is Mostly Thinking (2014)
#29Who hasn't accidentally thrown away a days worth of work with the wrong rm or git command? It is indeed significantly quicker to recreate a piece of work and usually the code quality improves for me.
Yes, that can often result in a better-designed refactored version, since you can start with a fully-formed idea!
Re: Programming Is Mostly Thinking (2014)
#30Programming 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!) alignment
2. key algorithms, state machines, flow charts (especially when modeling fail-safety in medical devices)
3. API, error handling, unit test plan, functional test plan, performance test plan
4. Alignment with compliance rules; attack modeling; environmental catastrophe and state actor planning (my experience with banks)
After all of this is reviewed and signed-off, THEN you start writing code.
This is what code development looks like when there are people's, business's, and government's lives/money/security on the line.
So. Much. Planning.