21 ms·

Advice for new software devs who've read all those other advice essays

• Valeriaazz 3y ago
  [flagged]
• johngossman 3y ago
  Some of these go beyond just advice for programmers. Everyone should reflect on the first point: most authors and essayists are read because they are good writers, not necessarily because they are experts on the subject matter. Take walks! Try different types of work. Learn about other job functions at your company. In big companies in particular, you may be doing things that just have to be corrected or worked around somewhere else, when you could make things easier for everyone.
• austin-cheney 3y ago
  1. Software does not make money. Not ever. Sales makes money. Software only costs money. When your developer peers get confused, distracted, or lost on this matter you better hope your employer is either too big, too stupid, or too wealthy to care. 2. The only purpose of software is automation. There is ultimately no other goal. When your peers start talking about frameworks, easiness, a bunch of tools, or other bullshit realize they have absolutely no idea what they are doing. Typically that occurs from some combination of narcissism, self-preservation, and stupidity. Either way when too many bad decisions occur your peers will burn you. 3. Becoming excellent at software is no different than becoming excellent at absolutely anything else. Software isn’t special. Practice. The people that argue against this are lazy and stupid. As an example of talent look at the Polgar sisters. 4. Just like with absolutely everything else being excellent at software means having enough challenging experience to form a vision around risk management, cost analysis, and unnecessary repetition. All of that should be tempered against novelty and asking the right extraordinarily critical/harsh questions. Most people don’t do any of this because of some combination of real life constraints and cowardice.
  • happytiger 3y ago
    There is no excellence in software — only advanced opinion.
    • wruza 3y ago
      There is. You just can’t be excellent at parts that are constantly changing. Avoid those who bumped more than 3 versions in a decade, they aren’t confident in what they want.
      • throwawaaarrgh 3y ago
        Excellence is a trap. It leads to hubris. An excellent programmer can be really annoying, and excellent code is unnecessary. Instead of excellence, strive for "working code", collaboration, quality, velocity, improvement, shipping the right thing at the right time. Use debt wisely and move forward.
        • marginalia_nu 3y ago
          In this episode of How It's Made: Mediocrity.
        • Bjartr 3y ago
          Excellence is a trap ... Proceeds to describe characteristics of an excellent developer
          • corethree 3y ago
            Right he's talking about a developer who is caught in the trap. A better way to put it, is a developer about thinks he's excellent. What someone thinks is, the majority of the time, not inline with what he actually is. Especially for developers who think they are excellent. Looking at you Brian Camacho.
  • preommr 3y ago
    > 1. Software does not make money. Not ever. Sales makes money. Software only costs money. When your developer peers get confused, distracted, or lost on this matter you better hope your employer is either too big, too stupid, or too wealthy to care. I feel like people exagerrate this idea to prove a point that, ultimately, sales is the gateway to money. Which is fair and important to keep in mind. But, worded like this, it goes too far. Sales and marketing do cost money. They can cost a lot of money, and it's not always as tangible as real product features. Non-marketing people tend to handwave away how hard it can be. And the product is important. It's much easier to sell a product if it has the features a client is looking for. To do otherwise is a whole different game that will also cost a lot of money but is feasible given certain conditions. For example, building a really strong brand where trustworthiness is more important than price/quality.
• happytiger 3y ago
  > From a person who really shouldn't be giving others advice. Ok, now I’m listening. Also, #8 is the best long term advice for programmers. Walk.
• kugurerdem 3y ago
  > People don't listen to me because I'm a good programmer, they listen to me because I'm a good writer. I think this point extends beyond the idea of guarding ourselves while reading the contents of good writers; it's also about how we should approach our jobs. Being a good writer will most likely improve your skills in dealing with other people. As software developers, writing and communicating with others is crucial to our work. I would also recommend beginners to write about the challenges they have encountered, their experiments, and their thought processes, among other things. If possible, they should write essays. This will prove to be a really useful skill later in their careers.
• codingdave 3y ago
  The one I have a hard time explaining well enough for new folks to get is: "It is not your job to write code." We use code as a tool to solve problems. Code is the mechanism of achieving our goals, not the goal in and of itself. If we are coding just for code's sake, we'll deliver the wrong results. We need to be focused on solving problems, and if we aren't sure what problem our code is solving, we need to stop coding and figure that out.
  • aleph_minus_one 3y ago
    > We need to be focused on solving problems, and if we aren't sure what problem our code is solving, we need to stop coding and figure that out. I am not sure whether this is a good advice - for a quite subtle reason: I do claim that most code (including most of the code that is written "for code's sake") does solve a problem, and most programmers at least unconsciously are aware of this fact - and that's why they write this "code for code's sake". The issue rather is that other people (say, "the suits") want that the code solves a different problem than the one that the code solves.
    • hef19898 3y ago
      Assuming tue devs don't live in a vaccum, it is other people eho define the problems to be solved. Doing so consiously, and not unconsiously by chance, is what engineering does. Producing something to produce something, while ignoring the problems you where handed to solve (doesn't matter if it is clients, customers, regulators or management), is pointless. The tricky bit is figuring what the real problem to be solved is, I agree. Ignoring that question and doing whatever comes to ones mind first doesn't really work so.
      • aleph_minus_one 3y ago
        > Producing something to produce something A central argument of me is that this situation "produce something to produce something" rarely happens - this is in my opinion rather evil propaganda from people who hate programmers and their way of thinking. Such code nearly always solves a problem - often one that the managers don't understand. Just to be clear: it does happen that the code solves a problem in a bad way - this is where in my opinion the trope of "code for code's sake" comes from.
• throwawaaarrgh 3y ago
  Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. It takes more time the first time, but it saves you time for the rest of your life. You will look like a genius because you'll have an encyclopedic knowledge of everything. You will avoid problems early that come from the subtle knowledge every piece of tech has, buried deep in the docs. You will learn to solve your own problems faster rather than asking other people about something, because the docs often have the answer. Read the source code of popular software you use (including the libraries of your favorite language). You can learn esoteric knowledge about programming just by looking at other people's code. One benefit of OSS is that many eyeballs can shave code down to very efficient forms, and you can take those forms for your code.
  • Waterluvian 3y ago
    Most documentation is not worth reading. It’s reference material to be reviewed on-demand. The “introductory” section that gives an overview is often useful, though. But that leads to the other problem: knowledge is not intelligence. You’ve studied some Python module but never learned that you ought to use a different one instead.
    • ChrisLTD 3y ago
      Agreed. Documentation isn't a novel or essay that you need to read to the end for it all to make sense.
  • mewpmewp2 3y ago
    Which documentation? If I read everything, it would take a lifetime.
  • BoppreH 3y ago
    Reading source code also helps steering you away from unfit projects. I've decided to replace dependencies after trying to submit a PR and realizing the code was not as robust as I hoped, or was doing too much.
  • random_kris 3y ago
• thedanbob 3y ago
  > 8. Take walks. I'm fortunate enough to have an office overlooking a small pond. When I'm frustrated I go to my window and stare at the pond for a while. When I'm really frustrated I walk down to the pond and stare at it for a while. I also walk to lunch as often as I can (i.e. when it's not freezing or boiling outside). Highly recommend.
  • TheHumanist 3y ago
    Gotta throw like... two sticks in the pond... or a couple rocks... that will help.
  • apantel 3y ago
    When you’re really REALLY frustrated, do you go into the pond and stare at it from the inside?
    • thedanbob 3y ago
      I can't say the thought hasn't occurred to me ;)
  • daqhris 3y ago
    Walks have helped me a lot in all aspects of life while dealing with problematic situations (as a refugee in Belgium). For the last couple of years, I have devoted my free time to a creative project called awalkaday.art.
• billy99k 3y ago
  A beautiful piece of code will always be outshined by something that works reliably and well.
  • itg 3y ago
    When I was younger, I was obsessed with writing clever code to show off my programming knowledge. Over time I realized code that is easy to understand is much more valuable.
    • billy99k 3y ago
      Same here. I've had really simple pieces of code in production for a decade with no issue.
• wolframhempel 3y ago
  My best bit of advice for any programmer at any level: "Don't make stuff more complicated than it has to be!" Software is complicated. Large, feature rich software is even more complicated. That's hard enough to manage as it is. The last thing you want to do is to throw a million of abstraction layers, frameworks, libraries, precompilers, transpilers, build steps, validation hooks, style checkers etc. into the mix. Each of them makes your project more complex by a certain factor. And not only do they add up - they multiply! Now, that doesn't mean that you need to built everything bare bones without the help of any third party software - just make sensible choices. Unfortunately, developers are way too prone to add another shiny thing to the mix. So here's how you decide if you really need something: At first: You don't - continue as is. Then: If the problem persists and the suggested solution keeps coming up, still refuse, but investigate the solution. At last: If the problem persists, the solution seems well suited to address it and it keeps coming up - accept that you have the problem and adopt the solution.
  • loloquwowndueo 3y ago
    I think an automatic code formatted actually makes one’s job easier, not more complicated.
    • max_sendfeld 3y ago
      Absolutely! I'm grateful that I don't have to worry about code formatting any more. But I remember in one of my earliest job the company used style checkers as a pre-commit hook that rejected your commit if they found trailing whitespace. That was before code formatting was part of your IDE. (Especially for us front end devs who used Notepad++ rather than an IDE at the time). And notepad++ had no easy way of showing trailing whitespace. So every commit was a dance of commit -> read rejection log -> remove trailing whitespace -> commit again.
      • EZ-E 3y ago
        I have memories at my post grad school where any deviations from the expected code source formatting led to a -1 on the mark. On the first few projects it was not rare to see students getting marks well into two or three digits negatives.
• cryptos 3y ago
  "Advice for new software devs who've read all those other advice essays" Ha! That reads like someone is trying to lure new developers into recursive essays! Be aware! :-)
• nottorp 3y ago
  > People don't listen to me because I'm a good programmer, they listen to me because I'm a good writer. That goes for all those talking heads on youtube too btw. They're not necessarily right, but they're good speakers/actors.
• CM30 3y ago
  The first item is also why it's good to be skeptical about things you learn on video sharing services like YouTube too. If you sound credible and present your ideas in a professional way, people will take them seriously regardless of how flawed they might be. In a world where a fair few 'essayists' have been exposed for just reading Wikipedia articles and Reddit posts, it's definitely good to try and not associate how people present their ideas with how accurate said ideas are. I'd also expand on point 10 to add that talking to these people often gives you a better picture of what problems your software/dev work is trying to solve, and can help you identify pain points that you may not have noticed yourself. Remember that with a (very few) exceptions, software isn't written for the sake of it, it's written to solve problems. Either way, nice list! Definitely has some useful advice there.
  • I_Am_Nous 3y ago
    This comment just made me consider LLMs as similar to the essayists you mentioned - they read the "right" answer somewhere on the internet/during training and then can regurgitate it in a way that makes sense without consideration of how true it is in practice.
    • yen223 3y ago
      Humans were hallucinating responses given a prompt long before LLMs were a thing. Just look at any comment thread.
      • I_Am_Nous 3y ago
        Certainly! It's generally considered a negative trait for LLMs to hallucinate but to say a writer is doing the same thing is kind of just implying they are a bad writer with a surface level understanding of their topic. I believe it's the confident delivery that's the issue, or the improper logical synthesis of ideas because they "seem" to be related.
    • CM30 3y ago
      Not even the right answer much of the time, just information that sorta matches the right patterns as requested by the user. But LLMs say things in such an authorative, intelligent seeming way that it's indeed easy to forget they have no idea what they're actually saying or how accurate it is at all...
• SillyUsername 3y ago
  Lip service is an important skill when dealing with toxic individuals. If it's unimportant to the project, agree and move on. E.g. "your code is badly written, but we've a tight deadline so I'm letting it pass the review". If it was a real issue it wouldn't pass, this is usually just stylistic criticism (unless of course you've ignored good practices like SOLID etc ;) ) and indicative of a new senior who still can't differentiate between functional and problematic code issues.
  • digitalsushi 3y ago
    The wink emoji is leaving me with the sensation I am out in the dark on something everyone else knows.
    • morbicer 3y ago
      I am not sure what the wink is, I think SOLID is mostly solid but my advice is be wary of anyone who is a zealot follower of Uncle Bob :)
      • ecshafer 3y ago
        Uncle Bob devotees that I have worked with, have also written some of the most confusing, inscrutable code I have ever seen. Dependency Inversion I think is a poor idea though. It is fine if you must have many different versions. But I often thing one solid concrete implementation is better. where this really goes wrong is when people are so into Dependency Inversion that there is an IClass for every Class, doubling the amount of files, and <5% of these actually have more than one implementation. IMO I think going by the original idea of Object Orientation from Alan Kay is the real winner: Its all about message passing.
  • tdeck 3y ago
    This is all fun and games until that person leaves the team or goes on vacation and some other project's tight deadline unexpectedly depends on understanding and fixing their poorly written code. People really discount the value of maintainable and understandable code until they've been in this position multiple times. Some people never learn it because they "fix" or modify things without understanding them, cause problems, and never reflect on how that happened.
• heelix 3y ago
  Code reviews are so impactful. Learning how to have others look at your code and provide feedback, and you looking at others and provide feedback is huge. Mixing in the junior devs into the mix, where they feel safe to ask what is going on here or why, is the perfect comment canary. Taking the journey from 'ugly, but acceptable' to polished only comes from feedback and looking at other's code.
• asimpletune 3y ago
  Most advice about programming is about writing code, but we rarely ever consciously consider how to improve at reading code. One way to do that is to read more code. If you read really good code, and I mean really read it, like a book, and absorb it, then you will improve so much. This kind of improvement is the most impactful, because you also spend most of your time as a programmer reading code than writing new code. Also, if you become good at reading code, then you don't need documentation.
  • sanderjd 3y ago
    Personally, I find it to be even better to step through code using a debugger. I think just reading down the text of a set of code files like a book has pretty limited utility. (Though better than not reading code at all!) It's like reading one of those choose-your-own-adventure books from start to end. Starting from an entry point and then digging into methods from there is better, but being able to inspect the runtime state and get a sense for the data layout makes the experience so much richer.
    • asimpletune 3y ago
      It's true that a debugger is easier to use, but it's limited in that you can't bring it all the places that you can bring your eyes. Also, as one improves at reading code a develops a mental debugger that can be brought anywhere your eyes can.
      • sanderjd 3y ago
        > it's limited in that you can't bring it all the places that you can bring your eyes. Why can't you? > Also, as one improves at reading code a develops a mental debugger that can be brought anywhere your eyes can. This is definitely true, but that "mental debugger" is susceptible to incorrect assumptions about the runtime state at the point of execution. If this weren't the case, far fewer bugs would be written in the first place, as this mismatch about assumed vs. actual runtime state is where most bugs emerge.
• williamcotton 3y ago
  The upshot of this is that a lot of the X you hear about have very small Y and will never get wide adoption, but it won't seem that way from how you hear about it. That's why it makes sense to be conservative. This kind of digital signal amplification is distorting any and all knowledge about our world! These will be known as the Digital Dark Ages to our great grandchildren. What, you say, with access to all this information how could it be? Are we not information technologists? Isn’t the answer obvious? Signal to noise. What’s the point of the information if the message is too distorted by the transfer medium to be coherent? The trick is then being skeptical without becoming cynical, not to withdraw but to balance. Probably to slow down. Like described by the last word in the quote, to be conservative. Chesterton’s Fence was shattered by an electric truck going 0-60 in 3 seconds, and as wood and stone splintered off of stainless steel and bulletproof glass, we all celebrated the global democratization of politics, labor and information. How do the Arab Spring, Lyft, and Google look 12 years after the party peaked?
  • ebiester 3y ago
    There are many ways to use the word conservative. In this case, I think he is talking about conservative in the technologies you choose to use in the critical path. You absolutely should learn languages (as but one example) outside the TIOBE top 20. You should be very selective in where you choose to implement them. (with exceptions, of course - TypeScript is likely a pretty safe choice now, but maybe wait to hitch your trailer to Mojo in a production environment.)
    • williamcotton 3y ago
      But he’s also situating this discussion in the context of how information about X reaches Y in the first place. I’ve expanded not the context but the content by replacing programming language/framework/tool marketing with every information transaction on the internet. Again, all of this is situated in a world of upvotes, advertising, global politics, venture capital, smartphones in every pocket, etc. The systemic effects are similar across a broad range of knowledge dissemination. It’s time to hit the brakes.
• amadeuspagel 3y ago
  > People don't listen to me because I'm a good programmer, they listen to me because I'm a good writer. The same is true of pretty much everybody you'll read. This is so important and so general. Even writers who make a lot of their real world experience like Nassim Taleb are still read because they are good writers. No one reads Jeff Bezos' letters to his shareholders, because he's not a good writer.
• masfoobar 3y ago
  Agree with many of the points raised in the link. Mine are simple - Leave your ego at the door.. especially if you are a new/young talented or "prodigy" programmer. Take any criticism on the chin. Be open minded and learn from it. Chances are they are not being negative towards you or your coding solution. In this indistry, people are going to be direct with their choice of words. Be honest. If you dont understand, ask for clarification. If you are writing code or using some library you have not used before - let it be known. You are not saying "you cannot do it" - imply you are excited to challenge and learn. Most young devs are generally like this. Co-workers will come in all shapes and sizes, and range from social to anto-social, alongside introverts or somewhere on the spectrum. I always try to meet-in-the-middle with everyone in this field. Feel free to raise concerns or ideas but at the end of the day respect the decisions being made even if you do not agree with it. People above you like seniors, leads, etc, have experience and may have got through past projects and know things. Of course, if you are "correct" in many ways, I am sure you will be recgonised (eventually) as you gain experience yourself. All this said and done --- Always be patient and dont worry if you are not "making an impact" in your department. Good things come with age.
• ta988 3y ago
  Don't stop learning. Be curious. Experiment. Exchange with others.
• liampulles 3y ago
  If you think that you've potentially fucked up big, seek help and own up immediately. Phone the person if they are not responding to messages. Everyone expects juniors to make mistakes, you'll earn respect if people know they don't have to worry about you delaying or trying to hide issues. Also, ask questions! Again everyone expects juniors to lack knowledge, and yet something about our schooling makes us embarrassed to ask.
  • HumblyTossed 3y ago
    > If you think that you've potentially fucked up big, seek help and own up immediately. Also, if you think you might fuck up big, partner with someone else first. "If you're going to go down, bring people with you."
• plagiarist 3y ago
  That debugging book is addressing something I've been thinking about recently: how does one help programmers advance their skills from a fresh entry point? I am convinced part of that is understanding how to use tools to inspect and solve problems. I'd probably buy that book based on this recommendation alone, but it is also something I was hoping to find. I believe other key parts of helping people advance are around teaching them how to read code and how to recognize/reduce unnecessary complexity, I don't really have solutions for that as of yet. There is plenty of text on DRY, SOLID, Law of Demeter, and so on, but I don't know how to move that knowledge from academic things one knows into tools for practical use.
• havkom 3y ago
  Great article and advice!! > Eventually the honeymoon will end and you'll learn that programming is frustrating and messy regardless of which Right Way people use, and that you can also make great software without doing it the Right Way. Over time you'll learn fifty other Right Ways and learn to mix and match them to the problem at hand. My impression though from last few years is that nowadays many developers get stuck being Right Way Guys and are unable to broaden their knowledge and views. This is sad and I do not know the cause of that if it is true. My speculation is that it has something to do with too short attention spans nowadays to efficiently expand knowledge in combination with being to comfortable in their current positions. Or maybe something with too much incentives to only learn specific frameworks and not basic knowledge of how things work “under the hood”.
  • marcosdumay 3y ago
    My guess is that professional developers are too concerned into getting into their new job next year. So they both don't have time to learn the lessons from this one (because they'll be out by the time those lessons hit) and they can't afford to not focus on the new great thing. That really impedes growth.
• hiAndrewQuinn 3y ago
  My 1¢ of advice: State is the enemy. Minimize state wherever you can. This includes state as in your code, state as in how many things you need to hold in short term memory to do your job, state as in how many project specific details you need to remember, all of it. State is the enemy. If you can derive it from first principles, always try to do so.
  • eschneider 3y ago
    I cannot stress enough how much you can reduce "how many things you need to hold in short term memory to do your job" by just keeping a notebook (or file, or wiki, or whatever works for you) and writing things down.
    • layer8 3y ago
      So, don’t derive it from first principles each time?
      • hiAndrewQuinn 3y ago
        Therein lies the wisdom
      • piuantiderp 3y ago
        Just the first time
    • apozem 3y ago
      I've been writing everything down in a notes app recently and I love it. If I think of a good Christmas gift for my brother in July, it goes in the app. If someone recommends an interesting-sounding book, it goes in the app. If an app at work has a specific or convoluted build process, it goes in the app. As someone who spent his entire childhood getting in trouble for forgetting things, it's been life-changing. Computers remember things so much better than my dumb brain.
      • themarlzy 3y ago
• zaptheimpaler 3y ago
  I've been working with one junior and one not so junior programmer on a hobby project recently, and they are both "Right Way Guys". For a roughly 300 LOC project with a discord bot and some rust code that only we will be running for now, they insisted on complete documentation, separate VMs for QA and "prod", systemd deployments, a templating system for a few strings, an ORM layer for four (4) SQL queries.. this is a project that maybe 10 people would use. These are only half the requirements for the "0.3" release with much more over engineering planned for the future. I have stopped working on that project :) It's frustrating and sad to see people do that. I was myself a "Right Way Guy" at the beginning of my programming for a few years, before I learned how much depth there is in CS besides junk like best practices and code style and how to focus on the only thing that matters - working code. They are often too convinced of their rightness.
  • Verdex 3y ago
    In the movie Primer, a group of four friends start a small computer business on the side. Two of them later invent a sci-fi box and then dramatic shenanigans ensue. Something I missed at first [1] was the significance of an event that happens early in the movie. They need to buy a $50 router because their existing one is broken. They have an impromptu meeting where one of the characters gives suggestions on how they could try to fix the existing router. The suggestions are all half spoken before being answered: "Did you try the ..." : "yes"; "well , how about resetting the ..." : "I tried that too". Clearly they're basically reading each other's minds because of how well they know each other and how much time they spend with each other. But then comes the 'punchline'. One character says 'yes' to buying the new router. The other response with "I need an 'aye'". Their side business apparently has very strict rules about what words they need to use for voting on decisions. It doesn't matter that they all know each other so well that they're finishing each other's sentences. It doesn't matter that this is a $50 router. And it doesn't matter that their income from this side business is inconsequential. The rules say that they need an 'aye'. My own theory with "Right Way Guys" is that some people have been able to find a lot of success by leveraging the knowledge that's stored in the hivemind of society. They don't really know what they're doing when you consider what's going on inside their skull. But they have successfully copied success up till now. The plus side is that they're able to inherit successful methodologies that have survived over time without having to do all the hard work themselves. The down side is that they literally don't understand when they're in a scenario where it will lead to failure. [2] [1] - I didn't think much of this until I watched the director commentary. Where they explicitly talk about how they intentionally setup this interaction to showcase how certain characters took the rules too seriously and which ones didn't take them seriously enough. [2] - My theory on my theory is that this is also why so many people encourage others to join in their favored cargo cult practice (be it software development or anything else). Social behaviors may or may not work, but the more people you can convince to follow them the greater the chance that when they fail catastrophically and/or fatally they're failing for someone who isn't you.
• epgui 3y ago
  My two cents as a professional engineer coming from biochem: While computer science / programming is very young and light on the science side, it has solid foundations in mathematics, and the mathematics that are true today will always be true. So I argue (without providing any proof) that it is almost certainly a good idea to “follow the maths” in your learning journey. I think this is as true for numerical algorithms as it is for functional programming and type theory.
  • tonyarkles 3y ago
    Yeah, I'm with you very much. There's a very clear distinction between "the foundations" of programming/software development, domain-specific expertise, and language/platform expertise. The foundational pieces are pretty much timeless; the platform pieces are ephemeral. Getting good at the foundational pieces ("the maths" as you call it) is a total game changer for being able to sit down with some new/unknown library or codebase and get to a level of understanding quickly.
  • staunton 3y ago
    Arguably, biochem also has "solid foundations" in physics. Would you recommend someone in your field to "follow the physics" in their journey?
    • epgui 3y ago
      Yes. Also follow the chemistry, and follow the maths. Any answer other than "yes" falls squarely in the anti-intellectual category... But of course all the usual pragmatism applies unless you are a point particle having indefinite lifespan.
      • staunton 3y ago
        > the usual pragmatism applies That sounds like by "follow" you don't mean "study a lot"... What do you mean then?
        • epgui 3y ago
• HumblyTossed 3y ago
  Before anything else, learn how to solve problems on your own. I know, we have this huge thing called the internet where everyone else has already solved every problem, but you really need to develop your own problem solving skills and looking up how other people did stuff won't help you do that.
• sevagh 3y ago
  Despite reading essays of other devs telling you how you should dev, have faith in yourself. Over time you'll develop your own proclivities, instincts, etc., and end up writing your own essays to the next generation. People writing essays are not writing it from some impossible point of knowledge or privilege. They're just you in the future.
  • layer8 3y ago
    But also, learn from history. Read books. Luckily, we don’t just have blog-post essays to go on.
  • ilrwbwrkhv 3y ago
    Yes most self taught programmers actually have instinctively a good way of programming if they learn it through hacking. It's a direct and straightforward way of programming not ruined by object oriented thinking or any of the solid principles bullcrap. What does the computer need to do? That is a powerful mindset to get into and building on.
    • staunton 3y ago
      This is true for people who have worked on big projects or had to maintain working software over time. However, I dare you to look at the kinds of code that "Jupyter notebook only needs to run once"-scientists write... Many of them have spent a lot of time hacking and can hack together something that runs and works on one input incredibly quickly. In a business, however, that's almost never what you want.
      • sevagh 3y ago
        I still think it's better than this scientist reading a bunch of books about software design patterns and trying to create something they don't really understand. Maybe like a "bad hacked-together first instinct" is easier to correct and build on than "misusing or mangling an advanced dev paradigm that you're not even good to enough to judge whether is appropriate for this usecase."
  • 3y ago
• matsemann 3y ago
  > But also don't worry too hard about getting "tricked" or learning "the wrong thing". Did I learn TDD when it was hip? Yes. Do I use TDD? No. But did TDD teach me how to write better code? Yes. Same with languages I've learnt but not ended up using professionally. Everything teaches you something. You can't find a good middle ground without stepping a bit too far in both directions.
  • diarrhea 3y ago
    > You can't find a good middle ground without stepping a bit too far in both directions. This is beautiful. So short, so apt, so instantly relatable and palpable.
  • Forricide 3y ago
    Couldn't agree more. Learning bad things - not that TDD is bad, or anything, but over committing to it might be - is a huge part of understanding why certain approaches are better or worse than others. Although, I suppose 'making mistakes is the path to learning' is already conventional wisdom, so.
  • x86x87 3y ago
    I think we all do a bit of TDD, just not the extreme kind. If you already have the code and now you're trying to extend it, thinking about how this is going to be done and writing a few tests around the usage makes sense. It also makes sense if you don't have the code but you do have a way to structure the code in your mind and you can figure out what parts you can build and test first. So while it's not TDD in the pure sense (it's more like Test Assisted Development) it is leveraging the spirit of TDD.
    • smolder 3y ago
      In a sense, even the way I use print statements and other outputs to validate the behavior of a non-TDD program at each iteration could be called test assisted or something. It's just in that case, the test is the whole program at each iteration, rather than something that is fully automated and decoupled from its normal operation. Each test then expands in scope with the scope of the program, not being preserved except perhaps as assertions or log messages.
• lolinder 3y ago
  > Julia Evans once said "behind every best practice is a horror story." If you don't understand a Best Practice, look for the horror story that inspired it. It might make the best practice make sense. It might turn out to be something that's completely irrelevant to you, and then you can feel comfortable doing a different practice instead. This is how I think of Chesterton's Fence. A lot of people read it as saying "don't tear something out until you know why it's there", which is, I think, half of the point. But the other half of the message of Chesterton's Fence is that once you can explain to him why the fence is there, you're entitled to tear it out if you still think it's a good idea. The point isn't to avoid changing things, it's to always understand the reasoning behind the status quo before changing it.
• programmertote 3y ago
  Very good article and I hope more people read it. Over my career of 15 years in software (data management), I have learned exactly that. One other thing that really helped me was something that I learned in my Theravada Buddhist upbringing: https://en.wikipedia.org/wiki/Kesamutti_Sutta https://en.wikipedia.org/wiki/Kesamutti_Sutta > The Kesamutti Sutta states (Pali expression in parentheses):[5] Do not go upon what has been acquired by repeated hearing (anussava), nor upon tradition (paramparā), nor upon rumor (itikirā), nor upon what is in a scripture (piṭaka-sampadāna) nor upon surmise (takka-hetu), nor upon an axiom (naya-hetu), nor upon specious reasoning (ākāra-parivitakka), nor upon a bias towards a notion that has been pondered over (diṭṭhi-nijjhān-akkh-antiyā), nor upon another's seeming ability (bhabba-rūpatāya), nor upon the consideration, The monk is our teacher (samaṇo no garū) Kalamas, when you yourselves know: "These things are good; these things are not blamable; these things are praised by the wise; undertaken and observed, these things lead to benefit and happiness," enter on and abide in them.' That advice is something that I found very useful in life even though I have become an atheist since I was in 8th-9th grade.
  • bmicraft 3y ago
    I have a hard time understanding what you mean by that, could you put it in simpler terms?
    • tejtm 3y ago
      I have not seen the like nor studied the field but interpret it as internal over external knowing. personal experience over dogma of any stripe.
      • bmicraft 3y ago
        I thought that might be a possible interpretation, but then personal experience is just an anecdote and also not a thing when you're just starting out
        • roncesvalles 3y ago
• tempodox 3y ago
  These are really good tips, sober and undogmatic.
• tomcam 3y ago
  At some point you will discover the Right Way to program, the thing which makes this all make sense, and you'll be convinced that the whole field would be so much better off if everybody else programmed the Right Way, too. Item 14: Write an article debunking Right Way whether you actually believe it or not. Free notoriety == easy job offers
  • deleted 3y ago
    [deleted]
• deleted 3y ago
  [deleted]
• carabiner 3y ago
  Advice considered harmful.
• salgorithm 3y ago
  HN hug of death. Here's the Wayback link. https://web.archive.org/web/20231220091455/https://buttondown.email/hillelwayne/archive/advice-for-new-software-devs-whove-read-all-those/ https://web.archive.org/web/20231220091455/https://buttondow...
  • neoromantique 3y ago
    [flagged]
• tikhonj 3y ago
  I'm such a fan of the debugging book[1] recommended in the article that I bought a bunch of copies to give out. I've given copies to friends, interns, data scientists and even executives, and everybody who's read it has appreciated it. The book has a small number of simple techniques that are great for solving problems in any large technical systems, so it's useful for almost everybody. It's also an easy and engaging read, with lots of "war stories" providing color and context for the otherwise-dry suggestions. [1]: https://debuggingrules.com/ https://debuggingrules.com/
  • DevAbdul 3y ago
    that's great, do you still have any to give out? i don't usually read books but i am trying to take it up lol. this may be a good way to staryt
    • goalonetwo 3y ago
      Did...did you just ask to get a free copy of the book?
• deleted 3y ago
  [deleted]
• deleted 3y ago
  [deleted]
• JensRantil 3y ago
  I used to keep a list like this on Quora: https://www.quora.com/What-are-the-best-secrets-of-great-programmers/answer/Jens-Rantil https://www.quora.com/What-are-the-best-secrets-of-great-pro... I used to update it a few times per year. Haven't done that recently. Maybe useful for someone else don't know.
• janee 3y ago
  "what advice would you give to xxx" Other than a means to gain advice, I've found this question a good gauge for collaboration compatibility. I often ask it in interviews on both sides to give me insight into what someone currently values. It's sort of like asking someone to define "better" be that in skill, or happiness or avoidance of pain. My main interpretation of the post would be a high value placed on pragmatism, gained via a journey of experimentation. Put crudely there is no silver bullet but try a few for a while I think point 10 is highly underrated in my opinion
• Moru 3y ago
  As a 50+ I have to say this. If you take away anything from that list - make it #8. It will save you so much problems later in life. (TL;DR: Take walks) To follow advice #6: If you need the horror story to understand, look up "Thrombosis".
• deterministic 3y ago
  Excellent advise. What works great for you or your team won’t work well for somebody else. So be humble about declaring your way to be “The Way”. For example, I prefer statically typed languages. It just works well with how my brain works. I am super productive. However I also understand that dynamic languages works better for some developers. That’s great! I will naturally seek out jobs and teams that prefer statically typed languages and they will seek out jobs and teams that prefer dynamic languages. No problem.
• mathildeasmund 3y ago
  [dead]