14 ms·

A bunch of programming advice I'd give to myself 15 years ago

• koliber 2y ago
  I rarely see advice with which I wholly agree. This is one of those rare times that I fully agree with everything g. Good seasoned advice from someone that has been doing this fo r a while.
• BiteCode_dev 2y ago
  Those are way too abstract advice when you start programming. You can only understand them because you lived those situations, which implies experience you don't have. I would say (specifically to my young self): - There is no substitute for doing. Less tutorials, more coding. - Stop being obsessed with quality: you are not at the level where you can provide it yet. Do dirty. Do badly. But ship. Some people will be mad at you, and they are right. But do it anyway. Yes, reboot the servers with users on it. Yes, commit the spaghetti. You'll reach the level you want to avoid doing all this. - The users don't care about the tech. They care about the result. - Doing something for the hell of it is worth it. Just make it separate from the point above so they don't conflict. - Programming is a battle against complexity. Again and again. Put that on a post-it. Make your decisions based on it. You will suck at it, but try. - You have imposter syndrome because you are an imposter. You are really bad. It's ok, doctors hurt people for years while learning to save them. Don't sweat it. It will come. - You need faith it will work out. On the long run, you'll get better at this. But in the short term also. You'll find the bug. You'll figure out the solution. It will happen if you keep at it even if it can be frustratingly long and unfair. Even if it doesn't feel like that right now. - The right team is way more important than the right tech. If you are alone, get in touch with people who will lift you up from time to time.
  • graypegg 2y ago
    A bit snarky, but I would add - don’t read opinions from a list and take it as gospel. Adapt to the jobs you’re in, and you’ll develop your own opinions, but now with experience to explain why. Opinions are formed by getting repeatedly hit with the consequences of your (and other’s) decisions, and everyone just has to take enough hits till the pattern seeking area of your brain takes over.
    • BiteCode_dev 2y ago
      I agree, and would say is equivalent to: > - There is no substitute for doing. Less tutorials, more coding.
      • graypegg 2y ago
        Yes true. Mostly just opining on the “list of everything you gotta’ know” is a bit TOO concrete IMO. (As opposed to too abstract) I was quoting out of similar things years ago at the start of my career, “it should be done this way because X said it” didn’t help me at all. It feels like insulation against being called too junior, since, you can just wholesale adopt someone else’s list of ideas and you’re good. But making mistakes because you’re new to the career is precisely what forms the base of those opinions in the first place.
    • efortis 2y ago
      I agree, form your opinions when you have enough information. For example, if you can’t decide between two data structures or tech, pick one and add a comment: // I’m not sure
    • FLT8 2y ago
      Maybe add to that: try to stay long enough in a role to really feel the consequences of your actions. Even better if you're on pager for a while too. I know it's not trendy to stay in a job for long these days, and conventional wisdom is it's not great for your salary either, but one thing it will do is allow you to understand whether decisions you made were actually good or not. There are roles I've been in where it's only been years later that the true impact of decisions made was actually apparent. I'm glad I hung around long enough to experience that.
      • scott_w 2y ago
        I wholeheartedly agree with this advice and have for over a decade now. I think there’s something in the fact that you know you caused that that helps the lesson stick. Potentially you will understand the assumptions you had then vs now that allows you to clearly see the underlying lesson to take.
  • dano 2y ago
    * This * - The users don't care about the tech. They care about the result.
    • bdw5204 2y ago
      To the extent users do care about the tech, they care about performance not how "clean" the code is or whether you're using the newest framework. Users hate when software is slow or uses an exorbitant amount of memory.
      • bazoom42 2y ago
        Most users have no idea how much memory a piece of software uses. They care about user experience though which means they will care if the UI hangs or is unresponsive.
        • graypegg 2y ago
          Bingo. I’d go further and say they don’t care about your application at all. They just want to do something, and your application’s quality is measured by how little it stands in the way of accomplishing that. The sad fact is this encapsulates features (ease of development, a framework probably does help you ship faster), adaptability (clean abstractions that are easy to work with), and performance. Finding that balance is always going to be hard but they’re all important!
      • dano 2y ago
        Yeah, I totally agree. Those other factors are internal optimizations. What gets me is when a team wants to switch horses to new tech and do a forklift upgrade just to implement something using the new hotness.
      • imhoguy 2y ago
        And if the product is aimed at prousers/communities who extend the functionality themselves with their own commands, scripts and plugins.
    • CM30 2y ago
  • marcusbuffett 2y ago
    These seem just as abstract as mine, if not more so, plus at least I provided examples where I could. Feels weird to criticize my post for general advice + examples, then come up with your own general advice without examples. Also this was just an analogy I know, but doctors definitely don’t hurt people for years while trying to save them, very different profession from ours, if anything doctors earlier in their career have been shown to have better results.
    • aniviacat 2y ago
      I think you are trying to address different audiences. While your tips are mostly targeted at people who are already working as programmers, the parent comment's tips are mostly targeted at complete beginners. E.g. this tip: - There is no substitute for doing. Less tutorials, more coding. is directly addressing a common mistake for absolute beginners. Many beginners will read (or worse yet, watch) loads of coding tutorials while doing little themsves. It is an issue a complete beginner encounters and understands. Your tip on the other hand: > If you (or your team) are shooting yourselves in the foot constantly, fix the gun is addressing people working on medium to large projects with internal tooling. That is not a situation a complete beginner finds themselves in; it's a situation someone who already works in programming for a while finds themselves in. I wouldn't necessarily say your tips are too abstract; they are simply too high level for a complete beginner. That is not necessarily a bad thing; perhaps the you of 15 years ago already had the basic understanding necessary to be able to comprehend and make use of your tips.
    • aiisjustanif 2y ago
      I really liked “You should know all the major shortcuts in your editor. You should be a confident and fast typist. You should know your OS well. You should be proficient in the shell. You should know how to use the browser dev tools effectively.” Typing skills are severely underrated in order to professions and roles adject to our professions like PM.
    • imhoguy 2y ago
      I think you both provide some kind of generational advice, like parent serving kid with life advice. Unfortunatelly, or fortunatelly, they will have to learn it by experiencing own failures first.
  • johnisgood 2y ago
    I have a very severe case of impostor syndrome. :(
    • lioeters 2y ago
      In a world of imposters, the half decent imposter is king.
    • bregma 2y ago
      Don't worry, you're not a real imposter. You've just inadvertently ended up in a position where you're expected to be one. Just fake it until you actually become a true imposter.
    • BiteCode_dev 2y ago
      You probably are. But most of your colleagues as well :) Most adults are kids in big meat suits, they fake it a lot. I started to live like I was not completely worthless at 35. Not saying that to be proud of it, just stating that if you think humanity should do better, the first person you'll judge is you. It will be glaringly obvious you are not meeting your own standards. The higher your standard, the longer it will take for you to reach them. And the way to get there faster is to ignore the shame, and do it anyway. Because if you don't, your growth will be slower, and you will do more damage for longer. Real life means real consequences. It will make you more tolerant of others as well. Way more tolerant.
  • penteract 2y ago
    > There is no substitute for doing. Less tutorials, more coding. This may be good advice for yourself in the past, and for many people at lots of times, but I'd hesitate to give it as general advice. Reading code others have written should not be understated as way to learn valuable things from fundamental patterns and algorithms to language features and idioms. If you have a job in a team, this may happen anyway, but it's possible to write lots of code without realizing there's a better way.
    • BiteCode_dev 2y ago
      Indeed it's not general advice, it's to me specifically, who used to procrastinate a lot under the guise of learning.
      • northrup 2y ago
        Same. I would fall into the same trap. One more article, another tutorial, another chapter of a book… juuust to make sure I understood the concepts; and what actually helped? Just coding, getting it wrong, fixing it, getting it wrong, fixing it, etc.
    • ffsm8 2y ago
      But you're not going to realize which way it's better unless you've written the bad code before.
      • BiteCode_dev 2y ago
        Tangential, but I think that's the problem with trying to learn from design patterns. I read about them and tried to apply them. That's backward and didn't produce anything good. I started to understand them by doing it the other way around: - Coding, solving problems. - Reading other people's sources. - Then reinventing half a terrible design pattern. - Later on, looking at a book: "ohhh, that's what I tried to do" or "ohhh, hence the snippet in that source". - Now I can discuss with people about the pattern and name my code entities according to that. Design patterns are a communication tool.
    • 2y ago
  • ourmandave 2y ago
    Stop being obsessed with quality: you are not at the level where you can provide it yet. Do dirty. Do badly. But ship. You'll reach the level you want to avoid doing all this. What if future you has reached that level and people on your team are shipping spaghetti?
    • rileymat2 2y ago
      I feel like this is bad advice, really, you need to be obsessed with quality and growth, but you can't let that stop you from shipping. Try for clean to the best of your ability in the time constraints you have, but accept that it will be dirty.
      • graypegg 2y ago
        I think aiming for clean is good, but it’s really hard to pin down what clean means when you’re starting out. I feel like just emulating what you see in your first few jobs is ideal. (As in, ask coworkers who know the thing you’re working on) It could be great code to be inspired from, or mediocre. Either way you get some input about what decisions result in what outcomes, and what the outcome “feels” like. And if it comes time to change one or many of those decisions later on in this codebase, the person doing it gets a uniform codebase to work from! Unique abstractions and fixes in random places makes refactoring harder.
      • BiteCode_dev 2y ago
        Obsession will stop you from shipping. Or it's not an obsession. It's caring. Very few people can pull off a Steve Job level of nitpicking and actually finish a project. I certainly couldn't, and that advice is for young me.
    • intelVISA 2y ago
      Then you find a new team, else you can do the classic 'making one trivial hill your Happy Path and be prepared to die on it' routine.
  • jameshart 2y ago
    > You have imposter syndrome because you are an imposter. You are really bad. It's ok, doctors hurt people for years while learning to save them What in the medical malpractice?
    • ponector 2y ago
      A recent Johns Hopkins study claims more than 250,000 people in the U.S. die every year from medical errors. It is ok to be an imposter.
      • jameshart 2y ago
        Is it your impression that the medical profession thinks that’s ok?
        • 4RealFreedom 2y ago
          Yes. Nothing is perfect. The remedy they've chosen is to rely on insurance. There is a reason we call doctor's offices 'practices'.
          • thfuran 2y ago
            There is, but it's not what you're implying.
          • switch007 2y ago
            You think they're called practices because of the less common usage of the term to mean an amateur learning something, to imply they're inexperienced/without training? Rather than it being the place where a practitioner works? ("someone whose regular work has involved a lot of training")
        • whamlastxmas 2y ago
          The medical industrial complex clearly thinks it is, otherwise there would drastically lower patient loads, allow more spots for medical school, and provide better working conditions that would allow for fewer mistakes. None of this is happening and is an implicit acceptance of medical error deaths
  • thfuran 2y ago
    >Do dirty. Do badly. But ship. Some people will be mad at you, and they are right. But do it anyway. Yes, reboot the servers with users on it. Yes commit the spaghetti. You'll reach the level you want to avoid doing all this. I think you're likely to reach that level a lot faster by trying and failing than by not trying at all.
  • cm2187 2y ago
    A way to rephrase your point about complexity is this wonderful quote "Developers are drawn to complexity like moths to a flame, often with the same outcome" (Neal Ford)
    • spoiler 2y ago
      I've experienced this too, but I never understood why this phenomenon happens. Is it because we start adding abstractions before we understand the problems? Like, there's a certain threshold where keep things too simple makes them too complex, so people start introducing abstractions to reduce complexity. But often it's the wrong abstractions and then we accidentally end up with worse complexity that's harder to unravel. There must be a term for this waves hand thing? Edit: gosh typical on phones is hard
      • devctx 2y ago
        The commonly used term, also mentioned by Fred Brooks, is accidental complexity. Accidental highlights the non intentional nature of devs introducing complexity.
        • spoiler 2y ago
          Isn't accidental complexity just complexity that's not part of the problem domain? Say in the context of serving content/downloads, accidentally complexity would be caching, proxies, CDNs (etc). Basically stuff that we have to deal with to handle or optimise downloads, but isn't inherently part of the "just downloading files" problem?
      • layer8 2y ago
        It’s because when you’re in the middle of things with a lot of context in your head, adding another little wrinkle feels like a negligible complication (in particular if the new wrinkle is ostensibly to reduce some complexity, or to ship more quickly), but those complications accumulate up to the limits of any developer’s comprehension (and beyond) rather sooner than later. Hence developers tend to work close to the limit of what they can handle in terms of complexity, which for anyone who hasn’t all the same context in their head (like the developers themselves some time later) is really more than they can handle in an effective manner. From another perspective, this is a form of entropy: There are many more ways to increase complexity than to reduce it. This is also the reason why biological life has been getting more complex over time, the only criterion being if it’s fit to survive and reproduce.
  • Zenzero 2y ago
    > It's ok, doctors hurt people for years while learning to save them. Modern medical education doesn't work this way.
    • BiteCode_dev 2y ago
      Yeah, I'm surrounded with medical professionals. It totally does. They make grave mistakes all the time. And they hide them. They lie about them. They have their ego and career on the line. And they don't have enough resources at their disposal, not enough hours, too many patients, and they are exhausted. In short, they are humans in a human system.
      • Zenzero 2y ago
        > Yeah, I'm surrounded with medical professionals In fact you are. You're speaking to one. Your original statement completely ignores the massive amount of barriers put up during your training. From my own experience I can tell you that students are usually quite self aware that they are learning and on a short leash. The most egregious mistakes I've seen were almost always a result of understaffing and gaps stemming from leadership issues coming from the top down. The small mistakes and cut corners are from tired overworked people. Nobody accepts "hurting people" as a component of training. It's an absurd statement.
  • TheRoque 2y ago
    I never really got the "it's ok to be an imposter", "it's ok to be bad" part... And the internet is full of people saying things like "I am a developer and I have no idea what I'm doing haha". Seriously, you might be inexperienced or not know everything, but you should clearly not be an imposter and you should be confident in your ability to improve and understand what you don't understand yet. Take responsabilities and ownership in what you do, don't get behind the easy excuse that it's too complicated. You are the professional and you are getting paid for this.
  • DrBazza 2y ago
    From 30+ years of dev work: > - There is no substitute for doing. Less tutorials, more coding. I'd rephrase that as "just write something!" Many times I find myself being the classic example of 'perfect is the enemy of good' - I'll think about the perfect solution, rather than write something *now*, that works, and refactor towards perfect. TDD and all that. Other things: - Beware the beta and the boss. If it works, it will invariably get shipped if your manager sees it. Many managers cannot put a value on the future cost of maintaining something that's barely good enough. - Classic Confucius: "I hear and I forget. I see and I remember. I do and I understand." If you're interested enough to read about some tech/language/framework, write something (again!). - Learn at least one other language and ecosystem in addition to your main one. Even if it is syntactically similar (C++, Java, C#, for example).
  • neilv 2y ago
    > Doing something for the hell of it is worth it. Just make it separate from the point above so they don't conflict. This is a great use for new, standalone open source modules: feel free to experiment with styles or techniques or goals that you wouldn't want to justify. (Or for experiments that you start and then abandon without ever showing anyone.) For example, when I was making lots of packages to help build out the Racket ecosystem, I'd already made an HTML-writing package, but I felt a craving to do one that used syntax extension at compile time, rather than dynamic s-expressions. So I just did it, as a separate package: https://www.neilvandyke.org/racket/html-template/ https://www.neilvandyke.org/racket/html-template/ I don't recall anyone saying they saw value in it, but I like it, and I scratched that itch, and added another skill to my programming mental bag of tricks.
  • karmakaze 2y ago
    Most of these lists do not advise on "programming" the task but rather "programming" the job/position. There's no problem with that, I'd just wish it was labelled "software engineering advice" or "advice for programmers". Few of the points are about programming itself and the list is overall pretty good. Consider this just a rant from an older programmer who hasn't fully recognized that 'programming' is now largely a social endeavor with online info for everything, language and library ecosystems, etc. I wonder how much of this information I would have internalized if it were all available in my time. Seems like the kind of thing I might read and nod in agreement and forget to apply when relevant without some hard earned run-ins (which is how I'd picked them up). As for actual programming advice, the thing I'd highlight is to look at the data first and foremost. It goes from initial conditions to post conditions. The differences are what your program/function does, but both the pre/post conditions should be able to be fully described as a valid static state. Once you understand that, the problem, the code is largely plumbing with a small part that applies the functional transformation. There's so much focus on the form and style of "the code" that seems to consider it the main thing rather than an artifact of getting the main thing done: think any time there seems to be fancy abstractions that don't provide value to offset its complexity. To relate it to a point in the post, if you can't connect the difficulty you're having with the logical transformation that needs to be done (e.g. from database state to state), it's likely self-inflicted (or it could be due to a poor choice of database schema). Similarly for poor choices of request/response formats--basically bad plumbing between systems (and not intrinsically hard because of the information being handled).
  • jerf 2y ago
    "Those are way too abstract advice when you start programming." I have come to the conclusion that the use of these sorts of posts is not that the reader, young or otherwise, will instantly and correctly apply all the lessons to their lives. It's more about sensitizing people to problems they may not currently see, and solutions they may not currently be aware of. It's about shortening the learning curve, rather than eliminating it. A 1-year programmer is not going to read themselves into a 20-year programmer, no matter what they read. But at the 5 year level I think you'll see a lot of difference between someone who never considers their craft and never pushes themselves, just keeps their heads down and doing the next bug, and the person who has even just occasionally read this sort of post, pondered how it may apply to their current situation, and taken out of it what they can... which may be something completely different than what they take out if they read the exact same post two years later.
    • password4321 2y ago
      Yes, countering "you don't know what you don't know"
  • ryandrake 2y ago
    > - The users don't care about the tech. They care about the result. Seasoned, grownup engineers and tech business leaders are forgetting this, even today. Users don't care that your product is made with AI, but techies just will not shut up about Generative AI, LLMs, Transformers and all this shit that should be implementation details. Users don't care about any of what goes into the sausage.
    • bazoom42 2y ago
      Investors care though, and for many startups the customer they need to appeal to is investors.
      • ryandrake 2y ago
        I don't understand why investors care, either. Product A is made with traditional algorithms, product B is made with AI and LLMs, product C is made with literal magic and wizardry. But they all do exactly the same thing. Why does an investor prefer to invest in product B?
  • khana 2y ago
    [dead]
  • YZF 2y ago
    I like this but I think all advice suffers from the problem of the people needing it being incapable of using it and the people who are capable of using it already know it. You learn by doing x time. There's also a place for study, reading, etc. to supplement this. This is true in software development. It's true in martial arts. It's true in chess. (the 3 things I've invested some effort in progressing in). I've taught martial arts but there's no magic advice I can give people that will instantly take them to the next level, they need to experience and work through things to progress. Having a teacher helps (a lot).
  • gofreddygo 2y ago
    Fine advice (better than OP). This works till you realize you're burned out, plus didn't get that promo, instead going to that bikeshedding worthless co-worker who's clearly less deserving. Motivation, productivity go out the window. You don't give a sh*t about the work, team, code quality, made up deadlines or real issues. Real maturity comes now. You learn to appreciate your limits, see what really matters despite what's being said and observe who make the calls and what their agenda is. And finally, when you've picked a path and it seems like it works, you'll find equilibrium, somewhere between an idealistic comment on a PR and your next interview. Till something else like health or kids rock the boat. Take it easy, you matter more to you than your work. 15 years on, only ones who will remember the weekends you spent at work are your family and kids. Get out more, find solace in the varied arts. Enjoy you painless body till it lasts. Make the weekdays show up between weekends not the other way. Laugh more. Eat well. Feel your surroundings. Make friends, keep friends. Make memories. Don't throw your life away chasing menial pursuits. If a piece of work is really that substantial and meaningful, it will show itself as such. Don't go looking for it.
• deleted 2y ago
  [deleted]
• hamasho 2y ago
  Most of this advice has already clicked with me, but this part: > If you can't easily explain why something is difficult, then it's incidental complexity, which is probably worth addressing That's a real eye-opener. Hope I remember this next time I implement something complex. The thing is, I don't think this stuff would've helped me much when I was a junior dev. A lot of them are just too nuanced.
  • j45 2y ago
    'Addressing' can be ambiguous. Writing comments to explain why it's right and needs to be this way? Or changing the code without considering if they have enough knowledge of the rest of the codebase. There's also a chance it's not understood yet to easily explain it. A key part of joining a team is remaining open to the fact that just because I don't understand something, doesn't mean there isn't understanding in it.
    • 8n4vidtmkvmk 2y ago
      Sometimes there's understanding, sometimes the person who did understand has left the team. This is why it's worth writing good commit messages and going back to read them when there's a funny piece of code. A lot of my commit messages are to the effect of "I did it this way to be backwards compatible with how it always worked. It still looks funny to me though" Then at least future person knows I don't have a good reason for it and they can dig deeper or get PMs to sign off on something better if they want.
      • j45 2y ago
        Definitely agree with this. Reading code is harder than writing it, and too many people don't have the patience for it. Instead, in cases like these they'd rather invest the time re-learning the lessons of the past because they thought it should be a certain way, and if they can't instantly see a reason why it's done a certain way, then they behave (unintentionally or otherwise) as if understanding is not possible. Especially where it's tricky it's worth including a larger pre-amble in the code itself, as well as source code control. Often one or the other are suffering, and it's sometimes worth giving a description of how the components work together in detail, or are relied up on by more than one use case (therefore not a simple change or solution).
• piterrro 2y ago
  > If you can’t easily explain why something is difficult, then it’s incidental complexity, which is probably worth addressing. This one is good and has been following me since I've became a manager. Thanks to you, I know how to apply that objection to "press" people when I feel we're dealing with this kind of complexity.
• trustno2 2y ago
  The one thing I disagree is the thing about editors. When I began coding I spent hours tweaking my vimrc file and learning all the essentially random shortcuts, and dealing with the absurdities of vimscript. (and debugging vim plugins that broke each other.) It felt like actual work while I was producing nothing. Now I just open vscode with default settings and I am productive right away. Who cares about editors, vscode is good enough. But maybe just vim sucks and I should have been playing with emacs all along, I don't know.
  • fragmede 2y ago
    When you began coding, was there vscode? These days there's lazyvim to let you skip all that fine tuning if you want to "just use vim".
  • bregma 2y ago
    I just open vi with default settings and am productive right away. I tried VS Code and couldn't get a "hello world" example to run out of the box after a half hour of trying. Who cares about other editors, vi is good enough.
    • trustno2 2y ago
      And it's fine. Do what works for you. I just don't think playing with editor endlessly is a well spent time. It makes you feel like you do actual work when you don't. In my opinion.
      • lemonwaterlime 2y ago
        You only play with the editor endlessly if you’re the type of person to play with the editor endlessly. My vimrc was set up over the years a bit at a time based on my needs. After several years, I did an overhaul based on what I truly need and don’t need from experience. I rarely change anything in it these days. Maybe a few lines if I start using a new language. With that stated, most of my vim use is still understanding buffers and motions, which takes no configuration.
      • 2y ago
• l2dy 2y ago
  > Keep doing the first sort of bug fix, and you end up with a mess. To avoid the mess, design with the fail-fast principle in mind, which brings you closer to the spot where an error occurred.
• bazoom42 2y ago
  > Assess the trade-off you’re making between quality and pace Very important! But also important to distinguish between kinds of quality. Using a sub-optimal algorithm or bad identifiers or copy-pasted code can always be fixed later. But some problems like a bad database schema is much harder to fix later.
  • zarathustreal 2y ago
    I’d say be very skeptical of this advice if you’re a beginner. You almost certainly aren’t qualified to identify quality so don’t intentionally leave any on the table
• myaccountonhn 2y ago
  This is interesting. If I were to complement the list, these are some items I’d add that helped me: - learn functional programming. Doing that was how I finally “grokked” programming and could solve problems more easily. Before I was ready to give up. - learn CS history. I studied UX and what I learnt was mostly one side of how to think about computing where you spoon feed users and remove things. There are other ways to conceptualize software and design, which would have left me less disillusioned. - learn fundamentals: data structures, networking, performance, operating systems, security, unix, math. These are so neglected in the industry, and we’re left with super complex systems we don’t actually understand as a result.
  • bloopernova 2y ago
    "learn fundamentals: data structures, networking, performance, operating systems, security, unix, math. These are so neglected in the industry, and we’re left with super complex systems we don’t actually understand as a result." I sometimes hold a "command line fundamentals" course for my teams. Just being able to understand the basics puts them above any team that doesn't. You have to know the ground you're building on. Otherwise even your foundation will be faulty.
    • trashburger 2y ago
      Could you please share an itinerary for this? I’d also like to hold a similar course but don’t know where to start.
      • bloopernova 2y ago
        Sure thing! This assumes everyone has macOS, but isn't very mac-specific. * Introduction Quick history of Unix * When you log in Difference between login and interactive shells System shell files vs user shell files .zshenv for environment variables like PATH, EDITOR, and PAGER .zprofile for login shells, we don't use it .zshrc for interactive shells Your login files are scripts, and can have anything in them * Moving Around ** Where am I? pwd = "print working directory" stored in variable $PWD Confusingly, also called current working directory, so you may see CWD or cwd mentioned ** What is here? ls ls -al ls -alt . prefix to filenames makes them hidden . is also the current directory! .. means the parent directory ** Finding my way around cd cd - dirs | sed -e $'s/ /\\\n/g' ** Getting Help From The Man man 1 zshbuiltins manpage sections ** PATH echo $PATH | sed -e $'s/:/\\\n/g' zshenv PATH setting ** Environment Variables env | sort EDITOR variable ** History ctrl-r vs up arrow ** Permissions Making something executable ** Prompts zsh promptinit zsh prompt -l ** Pipes Iterate to show how pipes work cat ~/.zshrc | grep PATH ** Commands *** BSD vs GNU commands BSD are supplied by Apple, and Apple often uses old versions GNU are installed via homebrew, and match those commands available in Linux
• idkdotcom 2y ago
  [dead]
• wruza 2y ago
  Not sure what 15 years means, but if that’s where I started: (Blasphemies warning) - Skip low level and go as high as you can. Ditch C, assembly, hardware. Take python, ruby, js. Never touched C++ cause it’s awful? Good. - All the money is in the hands of a client. If you’re taking it from someone else, best case you’re taking less than a quarter for essentially the same job. Useless leeches everywhere who perceive you as a magic money generator. Go around them once you’re confident. - Read sicp, htdp, taoup, but don’t take them to heart. Seriously, extensively test any idea you learn against reality, cause ideas may sound excellent out of context. - Pragmatic is the only way. Don’t listen to industry peasants jumping through imaginary hoops, they are crazy. Religion in programming is worse than religion irl. There’s insane amount of it in programming. Don’t argue, let them be. It’s actually easy to test approaches by yourself and learn your own ways. Most of these are just habits making no difference once learned. - Doing something together only turns out faster if you’re very good communicators. Good communicators are rare and you are not the one.
  • Panzer04 2y ago
    Curious why you'd skip low level. Pay? Industry? Knowledge not helpful?
    • wruza 2y ago
      Because I ended up doing “business” things that are far from low-level, and I sort of like it, never wanted to return to C/asm.
      • PaulRobinson 2y ago
        I’m glad you’ve found a happy place in your work, but maybe take some of your own advice, drop this bit of your religion and change this to “use the right tool for the job”. If you’re doing business logic in a micro service, C is probably the wrong choice. Python, Ruby, whatever probably makes more sense. But if we are trying to build a (very) high-performance trading engine, or a device driver for a new piece of hardware we are building, and you are on my team and you show up with something in TypeScript because “it’s better”, we are going to need a conversation about whether you’re in the right place. I love high level languages but I also know the problem sets when not to use it. I also know that if I am going to be writing something very low level, it’s a conscious choice and I’m going to invest in the tooling and the time to make sure my code is safe and secure. The more generic advice might be that if you love a particular language or approach you might want to work on problems where that language is a good fit. Likewise, if you like particular problems, you should learn the language others think are a good fit in that problem space.
• inatreecrown2 2y ago
  this is not on the content but on the website color choices for text and background: wonderfully well done, easy to read in dark mode. with this kind of sensible coloring i feel i don’t need eink devices for reading.
• simonw 2y ago
  This was great. I particularly enjoyed the "Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code" section, I'd never thought about how spending time writing "perfect" code means you don't get to figure out which aspects of that code actually matter.
• mannykannot 2y ago
  I like this a lot. While those commenters who say it is too advanced for novices have a point, I feel these are still issues worth thinking about - and coming back to - as they learn. The one exception is “Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code.” My experience with bad code is that it does not tell me much; instead, it presents inscrutable and baffling mysteries. From the caveats and examples, I think the author is trying to say something rather different; something like “don’t obsess over completeness” or other concepts of ideal software - especially, I might add, dogmatic concepts of this nature.
  • trashburger 2y ago
    I think you got the wrong idea from that sentence; the author is talking more about the feedback you get from your end-users and/or customers, rather than development feedback a la debug info.
    • marcusbuffett 2y ago
      No I actually do mean the feedback you get as a developer when you realize which “bad” decisions actually end up being tech debt and which were totally fine and just saved time
  • dgb23 2y ago
    The Bad Code advice is for people who have the tendency for perfectionism (apparently like the author 15y ago). My advice to me: write simple, dumb, repetitive code, but make an effort to be consistent. Consistent, dumb code is really easy to visually parse. The repetitions slide into the background and the differences stick out. The more code there is, the easier to see what goes together (data aggregates/structures), what the overall flow should be (control, conditionals, order etc.). Then it's easier to factor things out or how to express more clearly what the code does. But again, consistency is key. The code can be "bad", but it's very beneficial to do simple edits like renaming and reordering of things, grouping them under succinct comments so the structure stays clear. Younger me would do the opposite: inconsistent code that is complex. I think its impatience that gets in the way, rushing to build abstractions and factoring out things way too early or trying out competing ways to express the same kinds of things (playing around with code). Every programmer has their own tendencies and their own journey, so they need to hear different advice, in order to ignore it for now, but to have an AHA moment at some point when they realize why the advice was given.
• tossandthrow 2y ago
  > Spending time sharpening the axe is almost always worth it I hear this advice constantly. But I feel like it really need to be qualified. I have been in projects that never saw any real value produced because people constantly focused on DX, projects management, and other tools. Sometimes one just needs to do with tools at hand, and not worry if there are better tools.
• pharmacy7766 2y ago
  What about: buy Bitcoin?
• jakobov 2y ago
  Codeisforhumans.com
• metalrain 2y ago
  Very reasonable, solving bugs one layer deeper can be very valuable, if you don't go too deep into the rabbit hole.
• DanielVZ 2y ago
  I have one: Learn to become comfortable implementing and working on state machines. It might be one of the most useful abstractions out there that if implemented well leads to a great extensible design without compromising performance.
• megamalloc 2y ago
  Mostly pretty sound advice here, but oh, this rankles! -- "In situations where bugs aren’t mission critical (ex. 99% of web apps), you’re going to get further with shipping fast and fixing bugs fast, than taking the time to make sure you’re shipping pristine features on your first try." In 99% of web apps, your end users have no possible way of telling you that you shipped a bug, and your bug will remain there forever, frustrating users and losing your client money as they abandon your site. Telemetry won't help you either becuase you'll misunderstand the observations it provides.
• theideaofcoffee 2y ago
  > If you (or your team) are shooting yourselves in the foot constantly, fix the gun This is a reasonable step to take if you're working in a reasonable company with reasonable "management". If you're unlucky enough to be working under a manager that refuses to recognize there is a problem, even with compelling data, prepare for pain. In that case nothing is allowed to be done because "well, that's how we've always done it and doing something about it might upset someone". It's really time to quit and find something new at that point because there is generally no hope of turning that around. > If you can’t easily explain why something is difficult, then it’s incidental complexity, which is probably worth addressing See above. "That's how we've always done it, and someone is used to that work flow, so we can't change it." Sometimes this will lead to a legitimate Chesterton's Fence situation, in which case you'd want to regroup and rethink it. Otherwise, the batshit insane is the default. Target the latter. > Try to solve bugs one layer deeper "There is no time to do that! We have so many other projects!" While being blind to the fact (or better yet, burying their head in the sand and trying to ignore) that it's all self-induced. > Don’t underestimate the value of digging into history to investigate some bugs "We can't change that because one of our people close to management made that decision and it might drive them away." Good, get them out, that's the only way to really fix it. Ideally if the management that hired them is pushed out too. > When working on a team, you should usually ask the question "Who are you to question our wisdom? Who are you to suggest something else, it's working in production." These are great things to start conversations, but you have to start them in an organization that is willing to change and be willing to take your advice to heart. Don't waste your precious life trying to change what can't be change, no matter how much you want to see it change.
• brainzap 2y ago
  programming is such a young field wirh many iterations that good advice is hard. I should have probaly made my own programming language!
• photochemsyn 2y ago
  > "It’s really easy to write terrible code. But it’s also really easy to write code that follows absolutely every best practice, with 100% test coverage, and has been fuzz-tested and mutation-tested for good measure – your startup will just run out of money before you finish. So a lot of programming is figuring out the balance." The situation appears to be changing rapidly. 15 years ago there were no advanced code-generating LLMs, and while relying on them for the core logic without having a good understanding of the language and system is still a bit iffy, it does seem that they're pretty good for generating tests and spotting deviations from whatever your group has decided are best practices.
  • farmeroy 2y ago
    What sort of tests does it seem good at generating? I was hoping it would give me a decent start writing tests with Jest and React Testing Library for an already existing but untested codebase. It seemed ok at small components that I can also quickly write tests for, but the larger, messier things would receive useless, failing tests.
• vitus 2y ago
  The point that resonated most with me, and that I repeat every time someone early in their career asks for advice (or one thing I wish I had been told when I first started out) is "When working on a team, you should usually ask the question". Early in my career, I spent a lot of time reading unclear or obsolete documentation, poring over code, etc, when I could have asked the person sitting next to me and gotten an answer in 5 minutes. Sometimes, I didn't even know who the right person to ask was, but if I had just asked my tech lead, he would have been able to point me in the right direction. Claiming that it reduces your overall time from several hours to < 5 minutes is maybe a bit exaggerated, since it also takes time to figure out what question you want to ask in the first place. But it's still worthwhile even if you end up investigating for 30 minutes instead of 3 hours.
  • pavel_lishin 2y ago
    On the other hand, though, I really wish people would take at least ten minutes to do that digging through the code or reading through the documentation before asking. One, reading code in general is a good thing to do when you're new, and it's a skill that should be built up in general. Two, you might actually find what you're looking for, and answer your own question! It's a nice little boost to realize you're getting self-sufficient. Three, you'll have a lot more context for me, which will make it easier for me to give you the answer. "Hey, how come this function doesn't return what I expected" is a much harder question to answer than "This function says it returns a list of items a user has accessed in a given workspace, but it's returning an empty list; I've checked my local database and it has a good set of seed data I think, and from looking at the function there's nothing obviously filtering out users, so what's going on?"
    • liampulles 2y ago
      At my first job, at a consulting company, they had a good rule, which was basically "show initiative when asking questions". What this boils down to is if you ask how to do X, you should first research and think about it, and then you can say "I think Y is how I do X, am I on the right track?" A lot of the time, you'll answer your own question getting to Y. If not, it will save the person you're asking a bit of legwork, and show you are not trying to have them do your job for them and have respect for their time.
• mrits 2y ago
  I spent a ridiculous amount of hours tweaking my vim config over the last two decades. I've used vscode the last few years and rarely jump to vim to do some text manipulation (that I usually could do with a raw install)
• supriyo-biswas 2y ago
  I wish more articles talked about the usefulness of integration tests over unit tests. Personally, I feel that unit tests are overrated and rarely give the required confidence to inform the team whether something is ship ready, whereas integration tests on the common workflows means that even when a bug is introduced, very few users are affected.
  • sethammons 2y ago
    So much this. I have been at a few shops now that feel their integration tests are ok and their unit tests are proving >90% coverage and yet they break the login or auth flow weekly. An absolute aversion to e2e tests. As soon as I can make a test log in and create and read one record, and bake that into the release process (preferably gating merge to main and after deployment artifact generation) then the site no longer breaks every week. Customer pain and hours of dev work saved.
  • tracerbulletx 2y ago
    It seems from my experience that when you're working on a core library or tool where the API is the product and it's going to be widely used by lots of other teams, or even companies in the case of open source, then unit tests are very important. If you're on a product team they probably are a waste of time.
• valyala 2y ago
  My advices to new software engineers: - Always think how to simplify the code you write, since simple code is easier to maintain and debug. - Prefer writing dumb code than smart code. Smart code is good for programming contests. Smart code is very bad in production when it needs to be debugged or refactored. - Always think about improving the usability of the software product you work on. Users don't care about code. They care about UX of your product. - Fix small usability issues as soon as you notice them, since these issues are usually the most annoying for end users. - Do not start writing code with some popular design patterns. Just write the most simple code, which resolves the given task. Later, the best design patterns will evolve organically from the code solving the particular task. VictoriaMetrics development goals are based on these rules - https://docs.victoriametrics.com/goals/ https://docs.victoriametrics.com/goals/
  • necrotic_comp 2y ago
    I go a step further on "dumb code". Write code that is easy to reason about, understand, and grok the implications of. I spent a ton of time doing support and engineering on a trading desk, where our SLA for an outage was somewhere in the range of 30 seconds to 5 minutes. Having super simple code that makes it easy to understand what the code problem is (if not necessarily the business problem) lets you move on with life and let the business keep moving.
    • jiehong 2y ago
      For writing simple code, I often remind people that the first working code is not the one to commit. Just like a text draft is edited, once the code works, now is time to trim it and simplify it.
  • lukan 2y ago
    Or in short, KISS! (Keep it simple stupid!) And yes, users will notice the button that is only half visible quite a bit more, than a suboptimal sort algorithm.
• efitz 2y ago
  I loved the author's point on "incidental complexity". I would point out though, that even if you CAN explain why something is complex doesn't mean it SHOULD be complex. When the subject of "tech debt" comes up, I always tell the teams I work on to focus on tasks that improve our speed or agility in the future. I believe that many coding tasks actually have a negative dev cost over time, as they reduce the dev costs of future work more than they cost at the current moment to implement. (Of course the problem is that they have a positive dev cost in the current sprint, so good luck convincing decision makers...)
• Scubabear68 2y ago
  The author’s comments about knowing your business context and the potential impact of bugs really hit home with me. I have seen far too many teams using Facebook sized solutions for a few thousand users. I’ve seen developers slowed to an absolute crawl, terrified of shipping code, for a completely secondary operational platform with low volumes and non-critical data. All because the product people were misguided in their mission. And sadly, I’ve seen teams with almost non-existent security practices and knowledge happily banging out crap in financial services environments. And I’ve been blessed with teams understanding their position and fully embracing it. Financial services products with quarterly releases that were rock solid and well architected. Batch document processing systems with just a few dozen end users who worked closely with us developers to tune algorithms where sometimes we would ship multiple times in a day and re run batches in production. To be successful, teams gotta know if you’re at NASA level, or life threatening, or business critical, or somewhat critical, or just nice tooling, plus understand the cash flow / budget situation. As a dev you may not be privy to all that, but strive to know as much of this as you can. And of course, understand who you users are, and who your customers are, and prioritize accordingly.
  • trashburger 2y ago
    I am personally at the “nice tooling” level, but am currently building towards supporting other teams at the “business critical” level, so I try to apply the same rigour to everything that I do. It might make sense to also consider your dependents in similar scenarios.
• liampulles 2y ago
  "Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code". This is probably quite a cynical way of putting it (and it speaks to me, probably because I am quite cynical) though I don't know if a junior dev will really appreciate this. The way I would put it is: don't seek satisfaction from trying to make perfect abstractions for business rules no one quite understands, rather seek satisfaction from making your user's lives easier as efficiently as possible.
• whatsakandr 2y ago
  A variant on that I say on one of these is "Do the dumb thing" thing to find the right abstraction. I've seen so mucb code that didn't need to be written if someone had just done the dumb thing. On the flip side, I've also seen so much code that could be so much simpler if after writing the dumb solution, they went back and figured out a better one. I guess the takeaway is: Prototype.
• stevenking86l 2y ago
  This is one of the better advice posts I’ve seen. Especially the parts about finding the balance between shipping fast and shipping bug-free code. Too many engineers think their job is “great code writer” and not “value adder”
• avanai 2y ago
  > Try to solve bugs one layer deeper This is one of the main things I try to impart to junior folks when I’m mentoring them or reviewing code. It’s also one of the biggest red flags to me of someone who’s working above their level when I have to repeatedly press a more senior person to dig deeper and fix things at a deeper level. You need to take the time to understand why the bug happened, or you’re just going to be patching wallpaper instead of fixing the plumbing leak.
  • deleted 2y ago
    [deleted]
  • hinkley 2y ago
    I’m surprised by how many people cannot handle 5 Why’s. It’s substantially the same people who like wallpaper and putty.
  • hiatus 2y ago
    > You need to take the time to understand why the bug happened, or you’re just going to be patching wallpaper instead of fixing the plumbing leak. I think many would like to probe deeper but aren't afforded the time between sprint tasks. Management often pushes back for solutions that are good enough compared to exploration with an unknown duration until the solution is found.
    • default-kramer 2y ago
      Of course this can vary wildly, but I've never felt afraid to defy management on that one. Half the time, they don't even need to know. And the other half of the time... what are they going to do? Fire me? Fine, then their project will be filled with nothing but wallpaper-patchers and I'll be somewhere else doing good work. (And of course, sometimes just patching the wallpaper is the right course of action, but it's rare to find management capable of accurately assessing this trade-off.)
      • 8n4vidtmkvmk 2y ago
        Yeah, at a certain point I just stop caring what management thinks and just doing what I think is right. I usually don't get the recognition I think I deserve for preventing future issues but no one complains either.
• Anduia 2y ago
  Funny how he casually mentions JIRA as a process that slows you down. I get that his team does the issue tracking somewhere else? What does people use that is faster to process both for devs and the PM?
  • skydhash 2y ago
    It always depends on the team. And by team, I mean the people working on a somewhat independent part of the project (they don’t need to care about the minutia of some other parts). Issue tracking is a tool, but project managers always wants the tool to become the process. And that’s when you got daily standups, story points, epics, and fixed sprints (aka fake deadlines). Use the tool as a tool. As the devs, add issue and tasks that needs the attention of the team, comments on a ticket for knowledge retention. As the manager, schedule the ticket if its completion matters in a particular timeframe, use assignments and other fields to manage workload. Do all of these to help the team get things done. Anything else is a hindrance.
    • Anduia 2y ago
      Correct, but JIRA is not SCRUM. Why does the author mention JIRA as a process? Does he find it slow or convoluted compared to other tools? Or does he think that using JIRA means a PM is forcing the team to follow an unwanted process?
      • magicalhippo 2y ago
        > Or does he think that using JIRA means a PM is forcing the team to follow an unwanted process? Think that must be it. We use JIRA at work. We have very, very simple processes. We create issues, we assign them, we resolve them and they're closed when deployed ok. Minimal fuss. I also have access to a customer's JIRA. They have like 6-7 steps between starting working on an issue and saying it's deployed in test environment. Another 5-6 to say it's delivered in prod. I saw the flow chart for the steps and it made my head spin.
  • marcusbuffett 2y ago
    That was more of a subtle joke than anything substantive. I think JIRA is probably fine as long as it’s not like a religion
• yowlingcat 2y ago
  Agree with sibling comment saying these are too abstract. Here are mine: Fundamentals: - Ecosystem beats language and syntax - Use boring, battle tested technologies - Use the relational database to do the heavy lifting - Avoid caching unless you have a great reason - Code cleanliness comes from simplicity, not elegance - There's higher leverage from improved code reading ability over writing ability Professional: - You grow faster building in good industries over interesting codebases - There's higher leverage from improving the business over improving the code - There's higher leverage in finding mentorship over being an autodidact - Make T-shaped buy vs build calls: build the secret sauce, try to buy the rest Probably leaving a bunch out.
• hinkley 2y ago
  The trick is not in having advice to offer. It’s in having advice they will hear. Next month I’ll have been working in software for 30 years. Which means I would have a lot more common ground with me 15 years ago than most people will. that me with five years’ experience might not have understood at all. Me with five years’ experience suspected many things that were true but missed some important one. I’d probably have to feed his ego by confirming some of those things before moving on to the difficult bits. But who is to say that me with less Impostor Syndrome would be a better person? No, the main value in learning from the past is improving the future, not nostalgia or regrets or what ifs.
  • j45 2y ago
    Sharing advice others will be able to hear is one part, having an audience who wants to get where they are a little faster and easier is another. There was a while where too many jr devs wanted to learn it all and go through the phases of learning everything themselves without considering if others have maybe gone through something similar. Thinking one's self not qualified might mean you share a good thoughtful approach towards learning something. Thinking one's self is qualified and if it's too soon might mean otherwise. No matter the better I have gotten, having a healthy mistrust of one's work helps it become better in a lot of cases haha.
• CM30 2y ago
  Seems like some good advice here! The points about digging deeper into the cause of a bug and looking at the history of the codebase for more info are really good points to keep in mind for sure. And remembering to ask questions hits home pretty well too. There's always the worry that you're bothering people too much, and the balancing act between thinking whether you need to be asking for help early enough to make sure you're not going down the wrong path and not asking about every little thing without attempting to fix it yourself...
• anilakar 2y ago
  One more: Make developer velocity one of your top priorities. You should be able to give anyone in your team the repo URL and have them running unit and local integration tests in five minutes without prior knowledge.
• redevil 2y ago
  [flagged]
• 999900000999 2y ago
  I'll add one point. You are not your job. Don't take things personally at work. And never be afraid to leave if you're not fitting in with your company . I've left jobs over a few reasons, primarily bad managers, increased compensation, and bad code . If people are writing bad code at your company, to the point where you know it's going to come back to haunt you later, it's okay to just walk away . Don't embarrass anybody, don't escalate to a manager and explain how horrible the code is. I was in a situation where someone our team was effectively writing code that pretended to do things it really didn't. I got into a really nasty argument with half my team about this. I ended up putting in my two weeks, and then my manager was like oh you were right the entire time . Life is too short to deal with incompetent people.
  • oblio 2y ago
    Unless you have a lot of flexibility in terms of where you work, this type of advice is becoming less relevant in an IT job market that's in free fall. Much fewer devs can just jump ship at will than between 2003 - 2022.
    • 999900000999 2y ago
      In my situation it would have been much easier to just keep my head down until I was able to get another job. I ended up causing a lot of tension at work, the engineer who had wrote this code openly resented me . Usually when people are putting broken code into the code base it's a wider cultural problem, that you're not realistically going to solve.
    • mostlysimilar 2y ago
      > Unless you have a lot of flexibility in terms of where you work, this type of advice is becoming less relevant in an IT job market that's in free fall. > Much fewer devs can just jump ship at will than between 2003 - 2022. Citation needed. Good developers are just as in demand now as they have ever been.
      • icedchai 2y ago
• austin-cheney 2y ago
  The one piece of advice I would give myself 15 years ago: In the corporate world be very good at administration. You only need to just be good enough at programming to not get fired. Everybody has opinions on software techniques and nobody measures anything, so it’s really just a popularity/tool game. The only goals are retain employment or promote out of software, being good at software is just a distraction from the goals. If you want to be excellent at programming do it as a hobby and set your expectations right that it’s only a hobby.
  • bigdict 2y ago
    Could you expand a bit on what you mean by administration?
    • wavemode 2y ago
      Not OP but I would say, generally non-engineering things that keep the business people happy. Project planning, delegating tasks, dashboards and metrics (customer feedback, if you can acquire it, is a big plus), setting and meeting deadlines, and knowing how to sell yourself. There's that old (and very true) wisdom that if you solve a complex problem in two days, the business people won't think "wow, this guy is so smart and hard-working for solving that in 2 days." They will think "oh, this problem must not have been very hard to solve. Let's assign him extra work." Being a good engineer only gets you so far, career-wise.
    • austin-cheney 2y ago
      Writing ample clear documentation, precision of communication, dutifully fulfilling all timesheets, logging of work performed, attending all requested meetings, and always delivering work on time.
      • largelady97 2y ago
        [flagged]
        • 2y ago
• simpaticoder 2y ago
  "Don’t underestimate the value of digging into history to investigate some bugs." Valuable advice, and it particularly highlights the risk of global state and the benefit of understanding your runtime. Browsers have popularized flamegraphs, stack traces show you the frames down to the moment of error, but global state survives multiple stack traces and the one you're looking at may not be (probably isn't) the cause of the problem. There is global state, the heap, external systems, etc that change over time and with successive calls. This is true even in single-threaded environments, and is far more complex in general multi-threaded environments. I often feel this isn't clear to beginners nor is it clear to them how you go about investigating bugs within this context.
• moonshinefe 2y ago
  Good post, I agree with most of it. One that goes hand-in-hand with "just ask the question" is learning to know when to pivot. If you've hit a blocker, whether it's something to do with waiting on a teammate, client, or answer to a hard question, consider pivoting to another task to knock out some easy wins. Ideally the task you pivot to should require minimal context switching to get going. This way you won't lose productivity. Often if the blocker is a hard problem and you go back to it later, you might have a good idea after stepping away for a bit as a bonus.
• roughly 2y ago
  I think this is great for the craft of coding and solving problems. I’d add one more, along the vein of career advice: you’re hired to solve problems for the business, not to solve technical problems. If you can’t explain how the thing you’re doing makes an actual difference for the business, you need to reflect on what you’re spending your time on. I’ve seen too many technical teams be far too fixated on technical problems and unable to understand why they can’t get more headcount, funding, or recognition. Nobody writing checks cares about code.
• cratermoon 2y ago
  > Our server models are exactly the same as the DTOs we would write, so I just serialized those, instead of writing all the boilerplate, we can write DTOs as needed later if needed I worked on a system that used the protobuf types generated for communicating between services everywhere. There was absolutely nothing in any of the components of the system that didn't depend directly on the generated protobuf code. What made it even worse is that a backend system we called had multiple endpoints that used the same name for similar but slightly different things, so there wasn't, e.g. just a single Passenger type, but a bunch of different Passenger types across various packages.
• vindin 2y ago
  I would have told myself that there's going to be a new frontend architecture called "SPA," and a new framework related to it called React.js. And that I should stay far away from both of them.
• alberth 2y ago
  > If you can’t easily explain why something is difficult, then it’s incidental complexity, which is probably worth addressing That’s how I feel about git.
  • Spivak 2y ago
    It's a product of its time dealing with requirements and limitations that aren't much relevant anymore. As far as multiplayer save goes we have much more powerful tooling than we had back then. But I think git became so ubiquitous that even new solutions unburdened by needing to mimic git's data model end up bringing that complexity forward because of familiarity.
• BhavdeepSethi 2y ago
  Really great advice! Few that I would add based on my experience: - Engineers spend way more time reading code than writing it. So writing easy to read code is more important than writing fancy/complicated code just because it saves few lines of code. - Extension to above point. Having coding standards in the company is important so that it's for anyone to make changes to different parts of the code. If one engineer ends up writing code using their own standards, it makes life harder for everyone else on the team every time anyone else has to debug that code.
• hugodan 2y ago
  15 years ago? Just buy bitcoin
• atribecalledqst 2y ago
  > Don’t underestimate the value of digging into history to investigate some bugs I'm one of about 2 people at my company who goes on archaeological expeditions to understand when and why a bug was introduced. A nonzero number of times, I have found that the behavior was introduced on purpose over a decade ago, and sometimes it's addressing an edge case I didn't think about. History is valuable! (unfortunately the most common usage for me though is as a 'smell test' where I learn who wrote the code from the history and then decide based on my existing assessment of their skills, how suspicious I should be of that code) e; oh yeah one more story that's kinda funny. Just this week I saw some behavior that I didn't like and went to look at the code's history. I was the one who wrote the code I didn't like. But I had left a good enough comment on it that I realized there actually was no issue at all and my expectations were incorrect.
• standardUser 2y ago
  > You’re going to be renaming things, going to type definitions, finding references, etc a lot; you should be fast at this. You should know all the major shortcuts in your editor. Programmers love to think this matters. If you're doing anything more than the most rudimentary work, the time 'saved' by maximizing keyboard shortcuts is completely irrelevant. You're spending most of your time reading code, thinking about that code and thinking of what code you're going to write. When any programmer emphasizes how fast they are at completing these rudimentary tasks, my assumption is they are less adapt at the actual work of programming and instead try to 'git gud' at the keyboard wizard bullshit.
  • wiseowise 2y ago
    > my assumption is they are less adapt at the actual work of programming and instead try to 'git gud' at the keyboard wizard bullshit. Whatever lets you sleep at night.
• hardlianotion 2y ago
  Advice I'd give myself: Finish what you're doing.
• ChrisMarshallNY 2y ago
  > update our subscription layer to call subscribers on the main thread instead I often do this, but have been doing it less frequently, lately, because I don't want to force a thread switch, unless I know that I'll be calling UIKit functions (not always things that affect UI. Many "background" UIKit functions also require main thread). Instead, I clearly mention the thread state, in the API headerdoc description ("- parameter handler: A simple, no-parameter, tail completion. May be called in any thread.").
• osigurdson 2y ago
  One bit of programming advice I would give myself is, on large projects, ensuring that appropriate constraints are in place is more important than functionality. You want to be able to come back to an area of code after a few years (without looking at it) and everything that has been added should still make sense. Patterns that you don't want to see should be hard to do - the natural inertia will stop it from happening. Designing things that "allow people to do anything", while seemingly a benefit, end up causing a lot of problems in the long run. A reasonable argument might be that it should be watched / policed but this is harder in practice than in might seem. A lot of orgs are fairly decentralized, meaning that no central entity can make the call (probably a good thing imo). If appropriate constraints are designed into the system this kind of energy sapping discussion will not even need to happen in the first place. Essentially, adding constraints at t0 adds degrees of freedom in the future. Coding is a bit like a garden - you need to ensure that the garden makes sense as it grows.
• rudnevr 2y ago
  not a good advice at all. it's hard to interpret right and will probably change in 5 years anyway when the author reaches another stage. my advice would be much simpler: 1. Most of the time you'll be manipulating test. Learn options how to manipulate text professionally. That includes vim, bash, sed, awk, perl, and regexes in general, including lookbehinds etc. It's worth it. It takes a few years to learn but even the basic options give you the culture and approach how to do things faster. Most coders have trouble swapping two columns in a text file or finding unprintable character. 2. Learn hotkeys seriously. They're more consistent and uniform than UI, learn how change them, which tools are better designed for them, and organize some memorization scheme. It pays off a lot and gets into body memory, freeing up mental space. 3. Learn how to version your own code instead of creating multiple files and folders. Read git manual at least once. Learn how patches work, what is interactive rebase, and how to go back and forth, combining different changes from different branches. That gives you freedom to experiment with code on a larger scale. 4. Learn how to quickly test any framework/code. There will be countless situations where you have some piece of crap not producing the needed result, and you should be able to quickly prove it. For this p.1 is invaluable. I have my own json,xml,rest,kafka and text log parser and diff, and a few cloud, database and search clients which I tweak when switching jobs. It's all mostly written in standard unix tools, and can be literally retyped if needed (I worked on high security envs often). It's also isolates me from poor (non-)standard tooling different in every enterprise to which I only fallback when I already know the answer and need to prove it to a peer. The rest is subjective and optional. You can love or hate your job, you can love tabs or spaces, weak or strong typing, but the above will definitely makes it faster. What to do with the rest of that time is your decision.
• garcia3252 2y ago
  [dead]