13 ms·
Programming Is Mostly Thinking (2014)
- Almondsetat 3y agoDevelopers 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."
- n4r9 3y agoQuestion in my head is, can LLMs think algorithmically?
- datascienced 3y agoLike a bad coder with a great memory, yes
- f1shy 3y agoThe problem is the word “producing” of the parent comment, where it should be “reproducing”.
- Kwpolska 3y agoLLMs can't think.
- FeepingCreature 3y agoLLMs can think.
- tasuki 3y agoSource?
- FeepingCreature 3y agoI use them a lot. They sure seem thinky. The other day I had one write a website for me. Totally novel concept. No issues.
- tasuki 3y agoI have a similar experience. Just thought it'd be cute to ask you both for sources. Interesting that asking you for sources got me upvoted, while asking the other guy for sources got me downvoted :)
- tasuki 3y agoSource?
- Kwpolska 3y agoLLMs string together words using probability and randomness. This makes their output sound extremely confident and believable, but it may often be bullshit. This is not comparable to thought as seen in humans and other animals.
- kragen 3y agounfortunately that is exactly what the humans are doing an alarming fraction of the time
- yifanl 3y agoOne of the differences is that humans are very good at not doing word associations if we think they don't exist, which makes us able to outperform LLMs even without a hundred billion dollars worth of hardware strapped into our skulls.
- kragen 3y agothat's called epistemic humility, or knowing what you don't know, or at least keeping your mouth shut, and in my experience actually humans suck at it, in all those forms
- cpeterso 3y agoAsk an LLM.
- deepnet 3y agoInteresting question. LLMs can be cajoled into producing algorithms. In fact this is the Chain-of-Thought optimisation. LLMs give better results when asked for a series of steps to produce a result than when just asked for the result. To ask if LLMs “think” is an open question and requires a definition of thinking :-)
- dorkwood 3y agoDoes it really take four hours to sharpen an axe? I've never done it.
- misswaterfairy 3y agoDoing it right, with only manual tools, I believe so, remembering back to one of the elder firefighters that taught me (who was also an old-school forester). Takes about 20 minutes to sharpen a chainsaw chain these days though...
- xandrius 3y ago10/20 minutes to sharpen a pretty dull kitchen knife with some decent whetstones. Also, as someone famous once said: if I had 4 hours to sharpen an axe, I'd spend 2 hours preparing the whetstones.
- dclowd9901 3y agoI don’t really know what “think algorithmically means,” but what I’d like to see as a lead engineer is for my seniors to think in terms of maintenance above all else. Nothing clever, nothing coupled, nothing DRY. It should be as dumb and durable as an AK47.
- weatherlite 3y agoWe need this to be more prevalent. But the sad fact is most architects try to justify their position and high salaries by creating "robust" software. You know what I mean - factories over factories, micro services and what not. If we kept it simple I don't think we would need many architects. We would just need experienced devs that know the codebase well and help with PRs and design processes, no need to call such a person 'architect', there's not much to architect in such a role.
- Tade0 3y agoI was shown what it means to write robust software by a guy with a PhD in... philosophy out of all things(so a literal philosophiae doctor). Ironically enough it was nothing like what some architecture astronauts wring - just a set of simple to follow rules, like organizing files by domain, using immutable data structures and pure functions where reasonable etc. Also I hadn't seen him use dependent types in the one project we worked together on and generics appeared only when it really made sense. Apparently it boils down to using the right tools, not everything you've got at once.
- namaria 3y agoI love how so much of distributed systems/robust software wisdom is basically: stop OOP. Go back to lambda. OOP was a great concept initially. Somehow it got equated with the corporate driven insanity of attaching functions to data structures in arbitrary ways, and all the folly that follows. Because "objects" are easy to imagine and pure functions aren't? I don't know but I'd like to understand why corporations keep peddling programming paradigms that fundamentally detract from what computer science knows about managing complex distributed systems.
- throwaway9021 3y agoDo you have any resources for this? especially for the adhd kind - I end up going down rabbit holes in the planning part. How do you deal with information overload and overwhelm OR the exploration exploitation dilemma?
- fifilura 3y agoI wonder if good REPL habits could help the ADHD brain? It still feels like you are coding so your brain is attached, but with rapid prototyping you are also designing, moving parts around to see where they would fit best.
- f1shy 3y agoThere are 2 bad habits in programming: people that start writing code the 1st second, and people that keep thinking and investigating for months without writing any code. My solution to that: just force to do the opposite. In your case: start writing code immediately. Ni matter how bad or good. Look the youtube channel “tsoding daily” he just goes ahead. The code is not always the best, but he gets things done. He does research offline (you can tell) but if you find yourself doing just research, reading and thinking, force yourself to actually start writing code.
- lkuty 3y agoOr his Twitch videos. That he starts writing immediately and that we're able to watch the process is great. Moreover the tone is friendly and funny.
- deleted 3y ago[deleted]
- Barrin92 3y agoit'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 to work, and rework if necessary. This article is basically the peak of the bell curve meme. It's not 90% thinking, it's 10% thinking and 90% "just type". Novelists for example know this very well. Beginners are always obsessed with intellectually planning out their book. The experienced writer will always tell you, stop yapping and start typing.
- citizen_friend 3y ago> You just need to start to work, and rework if necessary And making changes on paper is cheaper than in code.
- jjayj 3y agoI'm tempted to break out the notebook again, but... beyond something that's already merged, what situations make paper changes cheaper than code changes? I can type way faster than I can write.
- The_Colonel 3y agoYour 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.
- rocqua 3y agoThere's a weird tension between planning and itterating. You can never forsee anywhere close to enough with just planning. But if you just start without a plan you can easily work yourself into a dead end. So you need enough planning to avoid the dead ends, whilst starting early enough so you get your reality checks so you have enough information to get to an actual solution. Relevant factors here are how cheaply you can detect failure (in terms of time, material, political capital, team morale) and how easily you can backtrack out of a bad design decision (in terms of political capital, how much other things need to be redone due to coupling, and other limitations). The earlier you can detect bad decisions, and the easier you can revert them, the less planning you need. But sometimes those are difficult. It also suggests that continuous validation and forward looking to detect bad decisions early can be warranted. Something which I myself need to get better at.
- raincole 3y agoI 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...
- skilled 3y agoThis 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 challenge is what many programmers refer to when they say that programming is interesting. Picked up the new edition[1] as it was on the front page recently[2]. [0]: https://www.stroustrup.com/PPP2e_Ch01.pdf https://www.stroustrup.com/PPP2e_Ch01.pdf [1]: https://www.stroustrup.com/programming.html https://www.stroustrup.com/programming.html [2]: https://news.ycombinator.com/item?id=40086779 https://news.ycombinator.com/item?id=40086779
- jeffreygoesto 3y agoThe hardest part is finding out what _not_ to code, either before (design) or after (learn from prototype or the previous iteration) having written some.
- thunderbong 3y agoNo code is faster than no code!
- silisili 3y ago
- anon115 3y agore·con·nais·sance noun military observation of a region to locate an enemy or ascertain strategic features.
- darby_eight 3y agoDid you want to grace us with any particular relevance of this knowledge or do you just wanna keep it to yourself? Sadly, after all these years programming, I have yet to discern any real vulnerability in the US government.
- 082349872349872 3y agoI think it was meant as a parallel; historically light cavalry (explorers) and heavy cavalry (exploiters) had different ideals*, different command structures, and when possible even used different breeds of horses. Compare the sorts of teams that do prototyping and the sorts of teams that work to a Gantt chart. * the ideal light cav trooper was jockey-sized, highly observant, and was already a good horseman before enlisting; the ideal heavy cav trooper was imposing, obedient, and was taught just enough horsemanship to carry out orders but not so much that he could go AWOL.
- qwery 3y agoJust guessing/reading: it's a metaphor. You could see the recon as the thinking from the article. The enemy and terrain are the code and various risks and effects associated with changing it.
- mock-possum 3y agoWait… you have the diffs… why are you retyping the lost code by hand? What am I missing?
- AlotOfReading 3y agoI'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 decided the company should standardize on remote access to a network drive at his house. The effect of this was that I'd occasionally come in the next morning to find that my previous day's work had been deleted. Before I eventually installed an illicit copy of SVN, I got very good at recreating the previous day's work. Rarely took more than an hour, including testing all the edge cases.
- smackeyacky 3y agoCrikey what a sociopath to work for. I’m sorry this happened to you.
- scotty79 3y agoWas your work better or worse second time around?
- AlotOfReading 3y agoProbably a bit of both, but hindsight helped. It doesn't usually end up exactly the same though. Regardless, whatever I wrote worked well enough that it outlived the company. A former client running it reached out to have it modified last year.
- bernardlunn 3y agoWith writing the second version is definitely better, sucks having to redo but improvement makes it worth while.
- dailykoder 3y agoI 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
- bradley13 3y agoI 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"?
- qwery 3y ago> 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".
- runesoerensen 3y agoI usually think of coding and programming as fairly interchangeable words (vs “developing”, which I think encapsulates both the design/thinking and typing/coding aspects of the process better)
- marginalia_nu 3y agoImplementing 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.
- ken47 3y agoGood programming is sometimes mostly thinking, because "no plan survives first contact with the enemy." Pragmatic programming is a judicious combination of planning and putting code to IDE, with the balance adapting to the use case.
- datascienced 3y agoThe first run with the IDE is like completing a level of a game the first time. The second time it will be quicker. I agree we can expand thinking to “thinking with help from tools”.
- wruza 3y agoThis. Programming is mostly reconnaissance, not just thinking. If you don’t write code for days, you’re either fully aware of the problem surface or are just guessing it. There’s not much to think about in the latter case.
- zubairq 3y agoI liked "Code is just the residue of the work"
- MartijnBraam 3y agoWho 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.
- nickff 3y agoI’ve often found it alarming to see how much better the re-do is. I wonder whether I should re-write more code.
- f1shy 3y agoAbsolutely. Parallel to thinking LOC is a good metric, comes with "we have to reuse code" Because lots of people think, writing the code is very expensive. It is not!
- kragen 3y agowriting it is not expensive. however, fixing the same bug in all the redundant reimplementations, adding the same feature to all of them, and keeping straight the minor differences between them, is expensive
- BossingAround 3y agoNot only fixing the same bug twice, but also fixing bugs that happen because of using the same functionality in different places. For example, possible inconsistency that results from maintaining state in multiple different locations can be a nightmare, esp. in hard-to-debug systems like highly parallelized or distributed architecture.
- Akronymus 3y agoI see "code that looks the same" being treated as "code that means the same" resulting in problems much more often than "code that means the same" being duplicated.
- demondemidi 3y agoProgramming 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.
- deleted 3y ago[deleted]
- hgomersall 3y agoAnd 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 overruns as reality highlights all the changes that need to be made.
- Falmarri 3y agoI 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
- demondemidi 3y ago
- hgyjnbdet 3y agoOff topic. I'm not a developer but I do write code at work, on which some important internal processes depend. I get the impression that most people don't see what I do as work, engaged as they are in "busy" work. So I'm glad when I read things like this that my struggles are those of a real developer.
- jmpavlec 3y agoSounds like you are a "real developer". Don't sell yourself short.
- lordnacho 3y agoThis is why domain knowledge is key. I work in finance, I've sat on trading desks looking at various exchanges, writing code to implement this or that strategy. You can't think about what the computer should do if you don't know what the business should do. From this perspective, it might make sense to train coders a bit like how we train translators. For example, I have a friend who is a translator. She speaks a bunch of languages, it's very impressive. She knows the grammar, idioms, and so on of a wide number of languages, and can pick up new ones like how you or I can pick up a new coding language. But she also spent a significant amount of time learning about the pharmaceutical industry. Stuff about how that business works, what kinds of things they do, different things that interface with translation. So now she works translating medical documents. Lawyers and accountants are another profession where you have a language gap. What I mean is, when you become a professional, you learn the language of your profession, and you learn how to talk in terms of the law, or accounting, or software. What I've always found is that the good professionals are the ones who can give you answers not in terms of their professional language, but in terms of business. Particularly with lawyers, the ones who are less good will tell you every possible outcome, in legalese, leaving you to make a decision about which button to press. The good lawyers will say "yes, there's a bunch of minor things that could happen, but in practice every client in your positions does X, because they all have this business goal". --- As for his thought experiment, I recall a case from my first trading job. We had a trader who'd created a VBA module in Excel. It did some process for looking through stocks for targets to trade. No version control, just saved file on disk. Our new recruit lands on the desk, and one day within a couple of weeks, he somehow deletes the whole VBA module and saves it. All gone, no backup, and IT can't do anything either. Our trader colleague goes red. He calms down, but what can you do? You should have backups, and what are you doing with VBA anyway? He sits down and types out the whole thing, as if he were a terminal screen from the 80s printing each character after the next. Boom, done.
- otar 3y ago> This is why domain knowledge is key. Very true. There’s a huge difference developing in a well known vs. new domain. My mantra is that you have to first be experienced in a domain to be able to craft a good solution. Right now I am pouring most of my time in a fairly new domain, just to get an experience. I sit next to the domain experts (my decision) to quickly accumulate the needed knowledge.
- hubraumhugo 3y ago> 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 there's a way to track interruptions to showcase this. [0] http://blog.ninlabs.com/2013/01/programmer-interrupted/ http://blog.ninlabs.com/2013/01/programmer-interrupted/
- atoav 3y agoThis and a high demand for my time is why I am roughly a magnitude more productive when I am in home office. Nobody bothers me there and if they do I can decide myself when to react. If you want to tackle particularly hard problems and you get an interruption every 10 to 20 minutes you can just shelve the whole thing, because chances are you will just produce bullshit code that produces headache down the line.
- phreack 3y agoThis 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.
- jll29 3y agoI once led a project to develop a tool that tracks how people use their time in a large corporation. We designed it to be privacy-respecting, so it would log that you are using the Web browser, but not the specific URL, which is of course relevant (e.g. Intranet versus fb.com). Every now and then, a pop up would ask the user to self-rate how productive they feel, with a free-text field to comment. Again, not assigned to user IDs in order to respect privacy, or people would start lying to pretend to be super-human. We wrote a Windows front end and a Scala back end for data gathering and roled it out to a group of volunteers (including devs, lawyers and finace people even). Sadly the project ran out of time and budget just as things were getting interesting (after a first round of data analysis), so we never published a paper about it. We also looked at existing tools such as Rescue Time ( https://www.rescuetime.com/ https://www.rescuetime.com/ ) but decided an external cloud was not acceptable to store our internal productivity data.
- willrftaylor 3y agoFunnily 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 park it really made me pause to wonder what on earth I had been doing all day.
- thunfischtoast 3y agoSometimes 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.
- BossingAround 3y agoSometimes, I spend an hour writing a perfect function, and then spend another hour re-reading the beauty of it, just to be pointed out how imperfect the function is in the PR review :))
- alex_smart 3y agoIn 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.
- progx 3y agoAnd most of the time thinking about things that should not be done.
- f1shy 3y agoA good explanation of this is given on SICP. Ist about solving the problem, not getting the computer to do something.
- ludston 3y agoAgree 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.
- guax 3y agoDebugging is not thinking? Reading, understanding and reasoning about why something is happening is THE THING thinking is about. Fluency increases the speed in which you move to other subjects but does not reduce your thinking, you're going to more complex issues more often.
- ludston 3y agoIt's not just thinking though. You're not sitting at your desk quietly running simulations in your head, and if a non programmer was watching you debug it would look very busy.
- makeitdouble 3y agoI'd wager the more technically fluent people get the more they spend time on thinking about the bigger picture or the edge cases. Bug fixing is probably one of the best example: if you're already underwater you'll want to bandaid a solution. But the faster you can implement a fix the more you'll have leeway, and the more durable you'll try to make it, including trying to fix root causes, or prevent similar cases altogether.
- ludston 3y agoFluency in bug fixing looks like, "there was an unhandled concurrency error on write in the message importing service therefore I will implement a retry from the point of loading the message" and then you just do that. There are only a few appropriate ways to handle concurrency errors so once you have done it a few times, you are just picking the pattern that fits this particular case. One might say, "yes but if you see so many concurrency related bugs, what is the root cause and why don't you do that?" And sometimes the answer is just, "I work on a codebase that is 20 years old with hundreds of services and each one needs to have appropriate error handling on a case by case basis to suit the specific service so the root cause fix is going and doing that 100 times."
- kstenerud 3y agoThis 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.
- sanitycheck 3y agoIt probably depends on the project? When I'm writing something from scratch in a few months I can bash it all out on a small laptop - it is (as you say) all in my head, I just need to turn it into working code. If I'm faced with some complicated debugging of a big existing system, or I've inherited someone elses project, that gets much easier with a couple of giant monitors to look at numerous files side by side - plus a beefier machine to reduce compile/run times as I'll need to do that every few mins. You may care more about picking a keyboard & mouse/trackpad/trackball/etc if/when you start to experience pain in your wrists/hands and realise the potential impact on your career if it worsens! Similar situation with seating and back pain.
- t43562 3y agoI often feel that having a "comfortable" keyboard/mouse/monitor is more important than a fast CPU or a fancy graphics card - just because of that slight extra feeling of pleasure/ease that lasts all day long :-). The advantage of them is that my monitors and keyboards usually last a long time so putting money into them is not as wasteful as putting it into some other components. One thing that surprised me though is that I recently bought a KVM to switch from desktop to laptop instead of a second monitor and this turned out to be both better and much cheaper. I gave away an older monitor to a relative and found that not having to turn to look at a 2nd monitor was actually nicer. Initially I really didn't want to do this and really wanted another screen but I had to admit afterwards that 1 screen + KVM was better for me. RAM and disc space just matter up to the point of having enough so that I'm not wasting time trying to manage them to get work done.
- ripe 3y ago
- cranium 3y agoNow 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.
- marginalia_nu 3y agoI think this is true for certain categories of coding more so than others. Copilot is above all fantastic for outputting routine tasks and boilerplate. If you can, through the power of thinking, transform your problem into a sequence of such well-formed already-solved tasks, it can basically be convinced to do all the key-pressing for you.
- ozozozd 3y agoIn the 2020s, we still have software engineering managers that think of LOC as a success metric. “How long would it take you to type the 6 hours work of diff?” is a great question to force the cognitively lazy software manager to figure out how naive that is. Nowadays I feel great when my PRs have more lines removed than added. And I really question if the added code was worth the added value if it’s the opposite.
- masswerk 3y agoConversely, how long would it take the average manager to re-utter any directions they gave the previous day?
- vladsiv 3y agoGreat article, thanks for sharing!
- sibeliuss 3y agoI certainly notice folks who code about 30 minutes a day line-wise, but that's just because they're distracted, or don't care. Also, very very rarely is someone just sitting around and pondering the best solution. It happens, and yes it's necessary, but that's forgetting that for so much work the solution is already there, because one has already solved it a thousand times! This article is straight gibberish except for perhaps a small corner of the industry, or beginners.
- teekert 3y agoIt's also: "Damn I just wrote this whole new set of functions while I could have added some stuff to this existing class and it would have been more elegant... Let me start over..." Writing (code) is thinking.
- sibeliuss 3y agoExactly. The code is the feedback loop.
- sph 3y agoTo me, it's the exact opposite. It's beginners who spend a lot of time coding, because of inexperience, and bad planning. The first thing they do when they have a problem, is to open their editor and start coding. [1] I have been in this career for 20 years, I'm running my solo company now, and I'd say I spend on average 2 hours coding a day. I spent 10 hours a day just thinking, strategizing, but also planning major features and how to implement them efficiently. Every time I sit down to code something without having planned it, played with it or left it to simmer in my subconscious for a couple days, I over-engineer or spend time trying an incorrect approach that I will have to delete and start again. When I was an employee, the best code was created when I was allowed to take a notepad, a cup of coffee and play with a problem away from my desk, for however long I needed. One hour of thinking is worth ten hours of terrible code. --- 1: If our programming languages were better, I would do the same. But apart from niche languages like Lisp, modern languages are not made for exploratory programming, where you play and peel a problem like an onion, in a live and persistent environment. So planning and thinking are very important simply because our modern approach to computing is suboptimal and unrefined.
- t43562 3y agoThis 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 something explained to you is quite different from bashing your head against a brick wall for hours trying to work it out yourself.
- figassis 3y agoThis. 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 3y ago[deleted]
- deleted 3y ago[deleted]
- openrisk 3y agoVarious programming paradigms (modular programming, object-oriented, functional, test-driven etc) have developed to reduce precisely this cognitive load. The idea being that it is easier to reason and solve problems that are broken down into smaller pieces. But its an incomplete revolution. If you look at the UML diagram of a fully developed application its a mess of interlocked pieces. Things get particularly hard to reason about when you add concurrency. One could hypothesize that programming languages that "help thinking" are more productive / popular but not sure how one would test it.
- lysecret 3y agoSo is good writing actually.
- spc476 3y agoAt my previous job, I calculated that over the last year I worked there, I wrote 80 lines of non-test, production code. 80. About one line per 3-4 days of work. I think I could have retyped all the code I wrote that year in less than an hour. The rest of the time? Spent in two daily stand up meetings [1], each at least 40 minutes long (and just shy of half of them lasted longer than three hours). I should also say the code base was C, C++ and Lua, and had nothing to do with the web. [1] Because my new manager hated the one daily standup with other teams, so he insisted on just our team having one.
- BossingAround 3y agoWere the intense daily meetings any help? I can imagine that if there's a ticket to be solved, and I can talk about the problem for 40 minutes to more experienced coworkers, that actually speeds up the necessary dev time by quite a lot. Of course, it will probably just devolve into a disengaged group of people that read emails or Slack in another window, so there's that.
- xvilka 3y ago80% of meetings are useless. Especially long ones.
- spc476 3y agoNot really. It was mostly about tests. Officially, I was a developer for the team (longest one on the team). Unofficially I was QA, as our new manager shut out QA entirely [1] and I became the "go-to" person for tests. Never a question about how the system worked as a whole, just test test tests testing tests tests write the new tests did you write the new tests how do we run the tests aaaaaaaaaaah! Never mind that I thought I had a simple test harness set up, nope. They were completely baffled by the thought of automation it seems. [1] "Because I don't want them to be biased by knowing the implementation when testing" but in reality, quality went to hell.
- chadmulligan 3y agoThat’s an iteration of Peter Naur’s « Programming as Theory Building » that has been pivotal in my understanding of what programming really is about. Programming is not about producing programs per se, it is about forming certain insights about affairs of the world, and eventually outputing code that is nothing more than a mere representation of the theory you have built.
- lofaszvanitt 3y agoEveryone knows this who is a programmer. So this article is for other people, like managers?, who don't know how to measure their effectiveness...
- BossingAround 3y agoAlso junior developers, who might not realize that they are paid to think, not write LOCs.
- deleted 3y ago[deleted]
- tmilard 3y ago...and getting stuck.
- ajuc 3y ago> 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.
- uraura 3y agoThat'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.
- f1shy 3y agoIf you say "I was analysing the problem, and evaluating different solutions, and weighting the pros and cons, for example, I thought about [insert option A] but I see [insert contra here]. So I also thought about [option B]... I'm still researching in [insert source]". I do not think that should be a problem. Is what I say constantly in our daily's. And of course, eventually I deliver something.
- brabel 3y agoGreat article. I just want to comment on this quote from the article: "Really good developers do 90% or more of the work before they ever touch the keyboard;" While that may be true sometimes, I think that ignores the fact that most people can't keep a whole lot of constraints and concepts in their head at the same time. So the amount of pure thinking you can do without writing anything at all is extremely limited. My solution to this problem is to actually hit the keyboard almost immediately once I have one or more possible ways to go about a problem, without first fully developing them into a well specified design. And then, I try as many of those as I think necessary, by actually writing the code. With experience, I've found that many times, what I initially thought would be the best solution turned out to be much worse than what was initially a less promising one. Nothing makes problems more apparent than concrete, running code. In other words, I think that rather than just thinking, you need to put your ideas to the test by actually materializing them into code. And only then you can truly appreciate all consequences your ideas have on the final code. This is not an original idea, of course, I think it's just another way of describing the idea of software prototyping, or the idea that you should "throw away" your first iteration. In yet different words: writing code should be actually seen as part of the "thinking process".
- vorticalbox 3y agoThis is what I do I right off the bat wrote down an line or two about what I need to do. Then I break that down into small and smaller steps. Then I hack it together to make it work. Then I refactor to make it not a mess.
- jbverschoor 3y agoPen, paper, diagrams.
- deleted 3y ago[deleted]
- lwhi 3y agoXmind and draw.io
- 3y ago
- thatjoeoverthr 3y agoI’ve faced this viscerally with copilot. I picked it up to type for me after a sport injury. Last week, though, I had an experience; I was falling ill and “not all there.” None of the AI tools were of any help. Copilot is like a magical thought finisher, but if I don’t have the thought in the first place, everything stops.
- richrichie 3y agoIt is an iterative process, unless “to code” is narrowly defined as “entering instructions” with a keyboard. Writing influences design and vice versa. A good analogy that works for me is writing long form content. You need clear thought process and some idea of what you want to say, before you start writing. But then thinking also gets refined as you write. This stretches further: a English lit major who specialises as a writer (journalist?) writing about a topic with notes from a collection experts and a scientist writing a paper are two different activities. Most professional programming is of the former variety admitting templates / standardisation. The latter case requires a lot more thinking work on the material before it gets written down.
- divan 3y agoGreat article! I've posted it in other comments before, but it's worth repeating: The best explanation I've seen is in the book "The Secret Life of Programs" by Jonathan E. Steinhart. I'll quote that paragraph verbatim: --- Computer programming is a two-step process: 1. Understand the universe. 2. Explain it to a three-year-old. What does this mean? Well, you can't write computer programs to do things that you yourself don't understand. For example, you can't write a spellchecker if you don't know the rules for spelling, and you can't write a good action video game if you don't know physics. So, the first step in becoming a good computer programmer is to learn as much as you can about everything else. Solutions to problems often come from unexpected places, so don't ignore something just because it doesn't seem immediately relevant. The second step of the process requires explaining what you know to a machine that has a very rigid view of the world, like young children do. This rigidity in children is really obvious when they're about three years old. Let's say you're trying to get out the door. You ask your child, "Where are your shoes?" The response: "There." She did answer your question. The problem is, she doesn't understand that you're really asking her to put her shoes on so that you both can go somewhere. Flexibility and the ability to make inferences are skills that children learn as they grow up. But computers are like Peter Pan: they never grow up.
- shkkmo 3y agoEdit: Aften writing this long nitpicky comment, I have though of a much shorter and simpler point I want to make: Programming is mostly thinking and there are many ways to do the work of thinking. Different people and problems call for different ways of thinking and learning to think/program in different ways will give more tools to choose from. Thus I don't like arguments that there is one right way that programming happens or should happen. I'm sorry, but yout entire comment reads like a list of platitudes about programming that don't actually match reality. > Well, you can't write computer programs to do things that you yourself don't understand. Not true. There are many times where writing software to do a thing is how I come to understand how that thing actually works. Additionally, while an understanding of physics helps with modeling physics, much of that physics modeling is done to implement video games and absolute fidelity to reality is not the goal. There is often an exploration of the model space to find the right balance of fidelity, user experience and challenge. Software writing is absolutely mostly thinking, but that doesn't mean all or even most of the thinking should al always come first. Computer programming can be an exploratory cognitive tool. > So, the first step in becoming a good computer programmer is to learn as much as you can about everything else. Solutions to problems often come from unexpected places, so don't ignore something just because it doesn't seem immediately relevant. I'm all about generalist and autodidacts, but becomming one isn't a necessary first step to being a good programmer. > The second step of the process requires explaining what you know to a machine that has a very rigid view of the world, like young children do. Umm... children have "rigid" world views? Do you know any children? > Let's say you're trying to get out the door. You ask your child, "Where are your shoes?" The response: "There." She did answer your question. Oh, you don't mean rigid, you mean they can't always infer social subtexts. > Flexibility and the ability to make inferences are skills that children learn as they grow up. But computers are like Peter Pan: they never grow up. Computes make inferrences all the time. Deriving logical conclusions from known facts is absolutely something computers can be programmed to do and is arguably one of their main uses cases. I have spent time explaining to things to children of various ages, including 3 year olds, and find the experience absolutely nothing like programming a computer.
- sam_goody 3y agoFamuosly described as the tale of the two programmers - the one who spends their time thinking will provide exponentially better work, though because good work look obvious they will often not receive credit. Eg. https://realmensch.org/2017/08/25/the-parable-of-the-two-programmers/ https://realmensch.org/2017/08/25/the-parable-of-the-two-pro...
- nycnutterjob 3y ago[dead]
- macpete42 3y agoCode is more flexible than text for drafting the idea. Later on it will expand into a fully working solution. Defining non functional interface definitions and data objects for "scribbling" the use case works best for me.
- burgerrito 3y ago* (2014)
- khaledh 3y ago"Weeks of coding can save you hours of planning." - Unknown.
- runald 3y ago"Everyone has a meal plan until they get a fruit punch in the face." -Tyson?
- pqwEfkvjs 3y agoSo the waterfall model is the best after all?
- idkdotcom 3y ago[dead]
- thom 3y agoI'm not sure that follows. If most programming is thinking, then it makes sense to minimise the amount of thinking that is wasted when circumstances later change.
- machine_coffee 3y agoWouldn't say so. An iterative model which has been up-front loaded with a firm architecture, feature elaboration, a rough development and testing plan, resources allocated and some basic milestones to hit so that upper mgmt. can get an idea when useful stuff might land. The development _process_ can be as agile-y as you like, so long as the development of features moves incrementally with each iteration towards the desired end-goal. But you have to be strict about scope.
- danielovichdk 3y agoWell of course it is. With progress in knowledge, there comes a stage before that. That stage we can call learning. I don't care how you bend it, learning involves thinking in its base of it all. So thinking does not merely make you a better programmer. It makes you a better programmer at every given time . Your progression never stops and like I just said, it's simply called learning.
- idkdotcom 3y ago[dead]
- knorker 3y ago> 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? The diff will help, but it'll be an order of magnitude faster to do it the second time, diff provided or not. For the same reason.
- sesm 3y agoI thought so too, but now I have different opinion. Programming has both analytical and creative part, which should be balanced. If you are over-analytical you don't get stuff done quickly.
- matthewsinclair 3y agoThis is also relevant in the context of using LLMs to help you code. The way I see it, programming is about “20% syntax and 80% wisdom”. At least as it stands today. LLMs are good (perhaps even great) for the 20% that is syntax related but much less useful for the 80% that is wisdom related. I can certainly see how those ratios might change over time as LLMs (or their progeny) get more and more capable. But for now, that ratio feels about right.
- hnthrow289570 3y agoSadly like half of that wisdom has to do with avoiding personal stress caused by business processes.
- matthewsinclair 3y agoWell, exactly. That’s kinda my point. Programming is so much more than just writing code. And sadly, some of that other stuff involves dealing with humans and their manifest idiosyncrasies.
- avodonosov 3y agoIf so, is it a good idea to base programmer interview on live coding session?
- porksoda 3y agoI love this type of interview. I code with the goal of showing how it's done, not how much I can do, and they very soon realize that they won't see finished code on "this" call. It's an opportunity to teach non-coders that hidden intricacies exist in even the smallest ticket. Usually just a few minutes in they're fatigued, and they know who I am.
- avodonosov 3y agoThe interviewers in a coding session are usually coders themselves, I think.
- cess11 3y agoI tend to spend a lot of time in REPL or throwaway unit tests, tinkering out solutions. It helps me think to try things out in practice, sometimes visualising with a diagramming language or canvas. Elixir is especially nice in this regard, the language is well designed for quick prototypes but also has industrial grade inspection and monitoring readily available. Walks, hikes and strolls are also a good techniques for figuring things out, famously preferred by philosophers like Kierkegaard and Nietzsche. Sometimes I've brought it up with non-technical bosses how development is actually done, didn't work, they just dug in about monitoring and control and whatnot. Working remote is the way to go, if one can't find good management to sell to.
- xondono 3y ago“Programming is mostly thinking” is one of these things we tell ourselves like it is some deep truth but it’s the most unproductive of observations. Programming is thinking in the same exact way all knowledge work is thinking: - Design in all it’s forms is mostly thinking - Accounting is mostly thinking - Management in general is mostly thinking The meaningful difference is not the thinking, it’s what are you thinking about. Your manager needs to “debug” people-problems, so they need lots of time with people (i.e. meetings). You are debugging computer problems, so you need lots of time with your computer. There’s an obvious tension there and none of the extremes work, you (and your manager) need to find a way to balance both of your workloads to minimize stepping on each others toes, just like with any other coworker.
- iraqmtpizza 3y agoIt's not nearly as unproductive as my old PhD college professor who went on and on about the amount of time you lose per day moving your hand off your keyboard when you could be memorizing shortcuts and macros instead of working
- Izkata 3y agoThe article isn't for programmers, it's for non-programmers (like management) who think it is mostly typing, and describing what's going on when we're not typing.
- arendtio 3y agoAn important difference is that in programming, it is often better to do the same thing with less code (result). I don't mean producing cryptic code-golf-style code, but the aspect that all the stuff you produce you have to maintain. This is certainly different from a novel author who doesn't care so much about maintenance and is probably more concerned about the emotions that his text is producing.
- cmrdporcupine 3y agoMost software developer jobs are not really programming jobs. By that I mean the amount of code written is fairly insignificant to the amount of "other" work which is mainly integration/assembly/glue work, or testing/verification work. There definitely are some jobs and some occasions where writing code is the dominant task, but in general the trend I've seen over the past 20 years I've been working has been more and more to "make these two things fit together properly" and "why aren't these two things fitting together properly?" So in part I think we do a disservice to people entering this industry when we emphasize the "coding" or "programming" aspects in education and training. Programming language skills are great, but very important is systems design and integration skills.
- msephton 3y agoI agree that programming is mostly thinking. But I don't agree with the how the post justifies it.
- JKCalhoun 3y agoSomehow the post seemed to miss the amount of time I seem to spend on "busy work" in coding. Not meetings and that sort of thing, but just boring, repetitive, non-thinking coding. Stubbing in a routine is fast, but then adding param checking, propagating errors, clean up, adding comments, refactoring sections of code into their own files as the code balloons, etc. There's no thinking involved in most of the time I am coding. And thank god. If 11/12 of my time was spent twisting my brain into knots to understand the nuances of concurrency or thread-locking I would have lost my hair decades earlier.
- kevindamm 3y agoAuthor listed a handful of the thinking aspects that take up the 11/12 non-motion work.. but left out naming things! The amount of time in conversation about naming, or even renaming the things I've already named.. there's even a name for it in the extreme, bikeshedding. Even sometimes I'll be fixated on how to phrase the comments for a function or even reformat things for line lengths to fit. Programming is mostly communicating.
- ivanjermakov 3y agoYep, with seniority programming gradually goes from problem solving to product communication and solution proposition
- citizen_friend 3y agoSeniority in helping large organizations navigate software development, not seniority in actually building software.
- interpol_p 3y agoIn my experience quite a lot of programming is thinking, though quite a lot is also communication, if you work in a team Typing out comments on PRs, reproducing issues, modifying existing code to test hypotheses, discussing engineering options with colleagues, finding edge cases, helping QA other tickets, and so on. I guess this is all "thinking," too, but it often involves a keyboard, typing, and other people A lower but still significant portion is "overhead." Switching branches, syncing branches, rebasing changes, fixing merge conflicts, setting up feature flags, fixing CI workflows, and so on Depending on the size of the team, my gut feel for time consumption is: Communication > Thinking > Writing Code > Overhead
- deleted 3y ago[deleted]
- ysofunny 3y agosame as writting
- tengbretson 3y agoThis really tracks for me. Personally, I have abyssal typing skills and speed. Not only has this never limited my productivity as a software developer, in some ways it has forced me to be a better developer.
- travisgriggs 3y agoIMHO Programming is mostly iterating (which involves thinking). The title, read alone, with only a brief skim of the article might give PHBs the notion that you can just sit developers in a room and let them “think” for 5.5 hours and the hand them their keyboards for the last 30 minutes and get the product you want.
- agentultra 3y agoToo true. I was introduced to a quote from cartoonist, Guindon: "Writing is nature’s way of letting you know how sloppy your thinking is." From Leslie Lamport. Although in my experience, thinking is something that is not always highly valued among programmers. There are plenty of Very Senior developers who will recommend, "just write the code and don't think about it too hard, you'll probably be wrong anyway." The whole, "working code over documentation and plans," part of the Agile Manifesto probably had an outsized influence on this line of reasoning. And honestly it's sometimes the best way to go: the task is trivial and too much thought would be wasted effort. By writing the code you will make clear the problem you're trying to solve. The problem with this is when it becomes dogma. Humans have a tendency to avoid thinking. If there's a catchy maxim or a "rule" from authority that we can use to avoid thinking we'll tend to follow it. It becomes easy for a programmer to sink into this since we have to make so many decisions that we can become fatigued by the overwhelming number of them we have to make. Shortcuts are useful. Add to this conflict the friction we have with capital owners and the managerial class. They have no idea how to value our work and manage what we do. Salaries are games of negotiation in much of the world. The interview process is... varied and largely ineffective. And unless you produce value you'll be pushed out. But what do they value? Money? Time? Correctness? Maintainability? And then there's my own bone to pick with the industry. We gather requirements and we write specifications... some times. And what do we get when we ask to see the specifications? A bunch of prose text and some arrows and boxes? Sure, some one spent a lot of time thinking about those arrows and boxes but they've used very little rigor. Imagine applying to build a sky scraper and instead of handing in a blueprint you give someone a sketch you drew in an afternoon. That works for building sheds but we do this and expect to build sky scrapers! The software industry is largely allergic to formalism and rigor. So... while I agree, I think the amount of thinking that goes into it varies quite a lot based on what you're doing. 11/12? Maybe for some projects. Sometimes it's 1/2. Sometimes less.
- perrygeo 3y agoWriters get a bit dualistic on this topic. It's not "sitting in a hammock and dreaming up the the entire project" vs. "hacking it out in a few sprints with no plan". You can hack on code in the morning, sit in a hammock that afternoon, and deliver production code the next day. It's not either-or. It's a positive feedback loop between thinking and doing that improves both.
- xvilka 3y ago> they have to recover from the previous day's backup This is how I know it's a work of fiction. Sadly, even these days daily backups in most organizations, even IT ones are an impossible dream.
- jshobrook 3y agoIn other words: the more useful Copilot is, the easier your job is.
- __MatrixMan__ 3y ago11/12 thinking 1/12 typing sounds about right to me, provided that we count typing things that we'll eventually delete as thinking and not typing.
- graemep 3y ago> typing and tools are not the most important aid to quick code production I think they are in an indirect way. Being able to touch type reasonably fast prevents the action of typing distracting you from your thoughts, or lagging so far behind your thoughts that it makes it harder to keep your thoughts clear in your mind. Maybe something similar with good tools.
- nevertoolate 3y agoI think OP means that problems are just too hard to solve without thinking Before starting to type. So basically the typing in part is decoupled from the real thinking, and just about picking up half ready ideas from the queue and deserialize it, so to say, as code.
- dryheat3 3y ago"Thinking out loud”… that’s how I view the process of writing code. I start with a concept, then think my way through the solution by writing code.
- _8j50 3y agoI thought it was 90% debugging? Perhaps it is 90% of the non-debugging that is thinking!
- NoPicklez 3y agoProgramming is mostly thinking just like many other knowledge related jobs, it's nothing special. This analogy can be used for most design related jobs, not just software. If I had my client report deleted today, I could rewrite that report in nearly half the time the next day because I remember the way in which I structured the report, the sentences that flowed that didn't and the way I conveyed the findings in a neutral way. No different to designing a physical product. You might see the outcome, but you don't see the numerous design iterations and compromises that came along the way which speak to the design that came out the end. Furthermore, there are going to be programmers that can write more code with less thought, because they might have many years of pre-thought knowledge and understanding that allows them to execute faster. This article sounds like it was written for a manager that doesn't see the value in the work performed, or simply doesn't understand design related work.
- k__ 3y agoI studied CS and taught programming 101. In my experience, the main issue with learning to code are all the contexts you have to remember. There is the static type level and the runtime level, all the scopes (class, object, function, nested functions, closures, etc.), the different machines (client, server, or even multiple servers, etc.) That's probably the reason why most devs start with dynamic languages and frontend/mobile. It can get just as complex as backend development, but at least you can eliminate a bunch of contexts when starting to code, learn what's left and then add contexts later.
- deleted 3y ago[deleted]
- netdevnet 3y agoThis is why I highly dislike the term "coding". It implies that the basis of the role is "typing code"
- Labo333 3y agoIn my experience (slightly tweaked towards data science and AI research), programming is also experimenting, be it playing with the data, testing a new idea or even debugging. There is a reason why LISPers (I'm not one of them though) praise so much REPL-driven development: the REPL is a laboratory. Also, how much time did you spend testing a library, looking on the internet how to install it, debugging the weird compiler errors? In the end you found the one option that made everything work but it took you hours of research and experimentation.
- effed3 3y agoSomemone say success is 1/10 genius 9/10 hard work (and a big supply of pencil paper and erasers), to -create- something (software too) is understanding how to do it right, not only how to do it work, is know the 'rules' (often standing on the shouders of giants) to maybe one day update (break too) those rules.
- elwell 3y agoSee also: "Hammock Driven Devleopment" (https://www.youtube.com/watch?v=f84n5oFoZBc https://www.youtube.com/watch?v=f84n5oFoZBc)
- nathan_compton 3y agoOne of the things I find interesting about the limited general intelligence of language models (about which I tend to be pretty deflationary) is that my own thought processes during programming are almost entirely non-verbal. I would find it to be incredibly constraining to have to express all my intermediate thoughts in the form of text. It is one of the things that makes me think we need a leap or two before AGI.
- graycat 3y agoIn my experience, of some decades, with programming of wide variety, in recent decades "Programming Is Mostly" (1) making sense out of missing or, as technical writing, badly written documentation needed to do the (2) mud wrestling of system management. Example 1: Had everything else working then needed a connection string or some such between my Visual Basic .NET code and SQL Server. Struggled with (1) and (2) full time for over a week, with frustration rising like a South Pacific volcano getting ready to erupt, finally reached by phone some relatively high executive who was surprised that anything so routine could be so difficult and quickly gave me the secret. Then my work raced ahead, no problems, and all my code worked fine. Example 2: Wanted a way for occasional, simple, routine file copying between two computers on a LAN (local area network) from both being connected to the same cable modem. Looked at the old "NET SHARE" and "NET USE", encountered mostly unclear, obscure, undefined technical terminology, tried to make sense out of the obscure syntax diagrams, observed that apparently nearly none of the many combinations of claimed options actually worked, and eventually, from two weeks of full time work, like throwing mud against a wall to see what would stick, underhand, back spin, side arm, etc., did a lot of guessing about what could be wrong and why (mostly involving computer security), discovered that likely computer A might be able to initiate a read from computer B but no way could computer B initiate a write to computer A, etc., got somethings working, but still need to document the effort. More problems on the horizon ahead: Problem 1: How to have on one computer at least two instances of the operating system on separate (bootable) hard disks and be able routinely (a) to back-up to additional internal and/or external hard disks all of the installed instances or restore from those backups and (b) recover quickly in case any hard disk fails or any bootable instance becomes corrupted. Problem 2: How to install PostGreSQL on Windows 7 Professional and/or Windows Server 2019 and get code in Visual Basic .NET to use PostGreSQL. Is there some good documentation?????? Will be thrilled to learn that in this case there is no problem!!! Once (1) and (2) are out of the way and, as results, the basic tools are working, the APIs (application programming interfaces) are well documented, then the syntax and semantics of the programming languages are easy and the programming itself is the easy, short, sweet dessert after all the nonsense before. The heap data structure, B+-trees, key-value stores, the .NET platform invoke, matrix inversion and eigenvalues, the Gleason bound, .NET managed memory, semiphores for controlling multiple threads, base64 encoding, HTML, etc. -- all really simple, fast, easy. (1) and (2) -- well over 70% of the effort.
- Vgoose 3y agoMy architect introduced Architecture Decision Records to my company and it's made a world of difference. Are there other tools and mechanisms people have found helpful to facilitate and scale group thinking?
- farhanhubble 3y agoProgramming is indeed thinking but thinking through coding. Think -> Code -> Evaluate. If you remove the thinking you have a code monkey. If you remove the coding you have analysis paralysis.
- Zobat 3y agoI once did a weeks worth of 'debugging/looking at code, trying stuff and testing' before committing my two lines of changed code. About 40 hours of work to produce what would take less than a minute to type. It wasn't even the worst code base I've inherited but it is the worst lines of code per hours worked I've ever had.