8 ms·
Developers 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
by Almondsetat 3y ago
Developers 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...