9 ms·
What I’ve Learned in 45 Years in the Software Industry (2021)
- yamrzou 4y agoPreviously: What I’ve Learned in 45 Years in the Software Industry – https://news.ycombinator.com/item?id=25658216 https://news.ycombinator.com/item?id=25658216 - Jan 2021 (345 comments)
- code_lettuce 4y ago+1 for SC's 7 habits Early in my career, my manager gave me the feedback that sometimes my eagerness to participate outsized my ability to understand. I never meant to suck the air out of the room, I was just so excited to build cool stuff! He recommended reading up on Stephen Covey and suggested that when collaborating on designs/debugging/etc. as a team, to practice being the last to speak. Life-changing advice.
- throwaway14356 4y agoI like to summarize everything said and add my own conclusions. It only belongs at the end.
- tleilaxu 4y agoSounds like a good manager, giving useful feedback!
- luuuzeta 4y ago>He recommended reading up on Stephen Covey and suggested that when collaborating on designs/debugging/etc. as a team, to practice being the last to speak. I'm unfortunately in the extreme end of that advice. I listen to my teammates but I rarely contribute anything worthwhile, not because I don't want to but because I've nothing to contribute. In two recent sessions about database design for one project and integrating SSO into another, I literally had nothing to say.
- wanderingmind 4y agoI think its a balance. While your questioning and speaking up should minimze the disruption, a junior person needs to learn to speak up even if the idea is totally dumb and crap. You cannot just listen to others speaking and learn to think and speak on the fly, just like you cannot look at swimming videos and learn to swim.
- noisy_boy 4y agoYou don't need to be the last to speak. Let the usual "speakers" do their bit first so that you know the main points that remain to be covered. If that means being last because everyone in your team is a "speaker" then you need to decide if you are ok with that dynamic. If no one on the team is a "speaker", maybe you have an opportunity.
- jordanmorgan10 4y agoI love this content! I love his wisdom! But my goodness, it's like some of these websites go out of their way to not be readable at all.
- rightbyte 4y agoNot his fault your terminal supports more than 80 character rows. (If you got Firefox click the reader mode in the right of the URL bar).
- jonsen 4y ago(Tried Reader on Safari iPad; Wow!)
- gumby 4y agoHonest question: what was the problem? The photographs? Photographs are almost always junk in an article, and this article was no exception, except it had the saving grace that this was his swan’s song,so why not (and there were merely three). But it was a simple text layout for a short article. Personally I can’t complain. Hence I ask what I’m missing.
- jsjohnst 4y ago> Honest question: what was the problem? > But it was a simple text layout for a short article. Personally I can’t complain. Hence I ask what I’m missing. Just wanted to repeat this as I entirely agree. Sure, it’s bland, but like it’s extremely readable and of all the sites to rant about UX on, this wouldn’t even make my top 1M.
- recursive 4y agoAll in all, I find it to be pretty readable. Some bigger body margins would help a lot though.
- rightbyte 4y agoIf you read it on a computer the text floats out the whole window width.
- deleted 4y ago[deleted]
- DrBazza 4y agoTwo bits of advice I'd add, from 30 years in the industry: * A colleague once said to me, a few years back, "become an expert in one thing", even if it's a small thing. * "My superpower is reading the manual"
- deleted 4y ago[deleted]
- lmg643 4y agoI think "reading the manual" can be be interpreted not just in the literal sense of whether there's an actual manual, but also in the metaphorical sense, to make sure we're considering easily available sources of information. Great advice.
- nickjj 4y agoYep this is a really important skillset. I've written a post around this topic because you can do this in a systematic way to learn pretty much anything https://nickjanetakis.com/blog/how-i-quickly-find-answers-to-problems-and-research-new-things https://nickjanetakis.com/blog/how-i-quickly-find-answers-to....
- mtlmtlmtlmtl 4y agoThe code is the best manual you'll every get in my experience. There's no substitute when working on a codebase. When I'm introduced to a codebase I'll be doing significant work on, I'll often spend hours at a time just reading the code. Start at main() and skim until you get a feel for the overall architecture, then go figure out whatever subsystems seem mysterious to you. Rinse and repeat. Makes a huge difference when making changes, because that requires reading code anyway, and you'll have a much better idea of what code to read/change.
- sigha887 4y agoAnd it will for all future make it impossible for you to distinguish official API and implementation details.
- joeyguerra 4y agoSolid.
- ahstilde 4y agomy close friend feels bti360 is the best contractor to work for.
- defaultcompany 4y agoI clicked through to their website and it is hmmm... different? Like I think maybe it was created using Microsoft FrontPage in the mid 90s and never touched again outside of posting new photos of company events. While trying to discern what this company actually _does_ (which is never really stated but seems to be like government security contracts?) I tried clicking on the "Apply Now" button and just got a lot of errors in the JS console. That being said I think this blog post actually is spot on and really does capture what it takes to do good software engineering.
- agumonkey 4y agohttps://archive.ph/wOlQm https://archive.ph/wOlQm
- mrwh 4y ago> Seek First to Understand Yes, this. If there's one issue I've seen again and again limiting engineers it's them fixing some part of a system without understanding the system as a whole, while assuming that someone (the code reviewer say) does understand it. It's a machine for manufacturing bugs and technical debt, and it keeps the engineer in a junior mindset.
- 123pie123 4y agoone bit of advice about contracting in the uk - given to me ages ago when I first started contracting is: "It's like playing a game where the rules change without you knowing and people cheat"
- plugin-baby 4y agoSounds grim. Any examples?
- peterangular 4y agoNot the person you're responding to but I've done a fair bit of contracting, although in the US. A perfect example is scope creep, which happens with all sorts of clients. And, as much as we all hate it as devs it's just the way the world works - stuff changes. Some clients will work with you to update the spec and make sure you're compensated for extra time, where others will just expect you to "roll with the punches" effectively working for free. A personal anecdote of this was when a medium-size company switched payment processors half way through our contract. I was building a custom subscription experience over a 3-month timeline. I had already finished the specified payment parts when they came to me wanting to switch it out for another provider... When explaining that change would effect timeline, and that I would need to be paid for the extra labor they got very combative. I pushed back on them and they threatened to pull the entire contract, sue for the 50% up-front (if not reimbursed), and even heavily alluded to slandering me among other customers of mine in their niche industry. They strong-armed me into doing the work because it was either losing two weeks redoing payment processor integrations, or losing over two months of work and potentially taking a huge reputation hit. Over the years they would reach out for new work, but I never contracted for that client ever again. Gotta pick 'em carefully and I don't tolerate abuse. On a contrasting positive note... Other clients understand scope creep involves extra work, and even proactively offer to pay for the labor/update timelines. For these folks I will bend over backwards because of the respect. --- So back to the "rules change" and "people cheat" - 100% accurate. Not all clients are like this - but, you have to learn to gracefully handle and eventually cull the ones who are.
- wiz21c 4y agoFor me it's : 50% of software development occurs outside the computer
- sigha887 4y ago90% would be more accurate.
- quickthrower2 4y agoTrue: marketing, sales, support, training, finance are part of holistic product the customer is buying into. The customer themselves is part of it too!
- antihero 4y agoOpen with a solution but be very open about its flaws, assumptions, and invite change. This is a great way to stimulate teams to start thinking.
- trm42 4y agoGood list. With a paltry experience of 14 years, I would add one silly thing that kind of feels too obvious to even add: When there's an error or exception, read the error and the stack trace thoroughly and figure out what it means even if it means googling. Lately I've noticed that younger generation doesn't really understand error messages even in the simplest cases and people end up in wild goose chases when the real reason was incorrect permissions or something really mundane.
- Tade0 4y agoThe error messages, at least in front-end, have gotten worse. In 2012 I had a stack trace that I could read and eventually figure out what happened. Nowadays it's async framework method calls upon async framework method calls and that is an improvement in the tooling, because it can now glue them together. Next-gen frameworks are undoing that mess, but god help you if you use some third party library for e.g. state management.
- deleted 4y ago[deleted]
- bigbillheck 4y agoI like to rag on c++ for having terrible errors, but they're way better than they used to be.
- pokepim 4y ago
- plugin-baby 4y ago> Lately I've noticed that younger generation doesn't really understand error messages even in the simplest cases It was ever thus. I suspect what’s happened is that lately you’ve become the older generation.
- gautamdivgi 4y agoI doubt that. I grew up learning to use a C debugger and interpret core dumps right from my undergraduate school. Knowing the error and inspecting the stack were something I just had to do. In the absence of google and stackoverflow the ability to inspect your core dumps and debug the stack were essential.
- abledon 4y agodoes css load for anyone else: https://www.bti360.com/careers/ https://www.bti360.com/careers/
- xiwenc 4y agoI’d like to add: accept imperfect solutions but try to think few steps ahead. It’s an art to produce something that lasts long but doesn’t take years to build. Tech evolves rapidly.
- deleted 4y ago[deleted]
- yodsanklai 4y ago> Solutions should be as simple as possible. Assume the next person to maintain your code won’t be as smart as you. This resonates. But I find it hard to tell to a bright person that their code or solutions are too complex.
- Forge36 4y agoI've found it harder to convince managers that code should be simpler. Sure a solution works, but it's a mess. This is especially true of my own code.
- amelius 4y agoI always liked this one: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." -- Linus Torvalds
- aprdm 4y agoVery good list!
- drchiu 4y agoI'd like to add: There's way too much stuff taken as dogmatic best practices when they're really not. Things change, improve, and there may be better approaches already in existence but are ignored because of some high profile person in the community. Keeping an open mind is key to being able to improve and use better approaches.
- xch 4y agoruby lock-ins?
- DrDog 4y agoGreat list. Is like to add theres no such thing as code perfection.
- Existenceblinks 4y agoHaha, none of these is "easier to hire" .. which is really dumb for that js library (the framework claims to be). Our industry is rotten and learns nothing.
- l0b0 4y agoMust be the first time I've agreed with every point in such a list. Is the company still in business though? Looks like the site is broken in several ways in both Firefox and Chromium.
- amazon_illegal 4y ago
- flippinburgers 4y agoHonestly I think #3 should be #1. And with that, entire frameworks and languages should just be thrown out the window by the entire industry. I'm sick of working with juniors who don't know how to find the simplest approach to problems without pulling in yet another 3rd party dependency ... or more likely want to write obtuse code because it makes them feel flashy. Just makes me want to shoot myself in the head.