> You know what the best part of being a software engineer is? You can meet and talk to people who think like you. Not necessarily the same interests like sports and TV shows and stuff. But they think about problems the same way you think of them. That’s pretty cool.
That hasn't really been my experience, for every 50 people I meet maybe 1 is here for the craft, the rest want to do 9-5, have a visibility at work, work on impactful projects but actually talk about their problems, their opinions in a deeper way - almost never.
> The most underrated skill to learn as an engineer is how to document.
Document why. I can read code. I want to know _why_ this nebulous function called "invert_parameters" that is 200 lines long even exists. Which problem did you have that this function solved? Why was this problem there in the first place? Write some opinions on maybe its intended lifetime of the codebase. Hell, I write comments that apologize, just so that a future reader knows that the code I wrote wasn't meant to be great but that I was in a time crunch or a manager was breathing down my neck, or that some insane downstream/upstream thing did something... well, insane.
Paint some picture of your mindset when writing something, especially if it's non-obvious, as that'll give all the additional context not captured in code, when reading the code.
Obviously this isn't the only good documentation rule, but I wish people - juniors and seniors alike - would do this more often, especially at the workplace.
Sadly I have rarely seen people doing this. These shadow knowledge usually went away with their owners when they left the company, left other people scratching their heads.
> Don’t meet your heroes. I paid 5k to take a course by one of my heroes. He’s a brilliant man, but at the end of it I realized that he’s making it up as he goes along like the rest of us.
As a child and adolescent I always imagined that something would click when I became an adult and I would become good at things and understand the world. That never happened, and then I realised it never happens for anyone. We're all just large children walking around figuring things out. Some of us figure things out faster, some of us stop trying to figure things out, but we're all just as clueless in the grand scheme of things. It's a miracle and a testament to our perseverance and ambition that things still work as well as they do.
On the other hand, I've contacted several of my heroes (not been able to meet as many of them in person) and that's always been an exhilerating, formative experience. I strongly recommend it if you can think of a good reason. (I have a list of heroes I have yet to reach out to because I haven't yet encountered an interesting enough problem to offer them. Several of them unfortunately have an actuarial deadline not too far into the future.)
I once worked with someone well renowned in my circles who gave talks, ran a blog, was cited/edited other peoples books.
His code did not match the hype, to say the least. His SDLC even less so.
There is probably an ego associated with being renowned that doesn't align with team-based work. He likened basic things like code reviews or PRs to being brought before The Hague and that the rest of the team was a bunch of bureaucrats.
I am not sure which profession they are in (software development?), but no. Not everybody is guessing. If they were you would have half of the buildings and bridges collapsing and the other half on fire by bad electrical wiring.
You can legitly learn how to do things properly and people who learnt to do that do the polar opposite of guessing. It is just that the world of software development has yet to be made liable for their results in the same way as civil or electrical engineers. So in software development many are just guessing because guessing wrong won't ruin their life.
- Drinking wine solo is odd. Whiskey, vodka, or beer (and if you Russian) is the standard. Spelling mistakes like 'ever thing' support the idea of alcohol induced unordered thoughts, that's good.
- Webdevs would one of the last to consider to be experts.
- While I don't use darkmode, browser extensions solve the unsupported web pages. Dark mode used to be the only possible option on a black/green screen, glad that changed.
- Pharmacist require a degree and quite a few years of studies and exams with tons of organic chemistry.
- HN comments being worthless is an awkward one. Lots of posts (e.g. Apple CEO change) had tons of useless stuff but it's very often the comments would bve better than the post itself.
IMO drinking is a very personal thing so I almost always drank solo. Like playing piano — I always thought playing in public very weird, almost equaling naked in public…
If there's any 20-somethings here that make 6 figures, listen carefully:
1. Max out your 401k, and invest all of it in a target date retirement fund. (Some companies are douches and will assign you mostly their own stock, which when it tanks, there goes your retirement... so check your allocation)
2. Get an HSA and max that out. Invest it all in a target date retirement fund. Do not use any of it, pay for medical expenses with cash and save your receipts. Get reimbursed for the receipts when you retire.
3. Contribute to an IRA and max it out (or backdoor roth when you make enough that that's necessary). Invest it all in a target date retirement fund.
4. Keep 6-12 months of living expenses in a high yield savings account.
If you start when you're 23, and you make $100k/yr, you can retire at 45. That may sound very old right now, and you might think, I'll just save later. But consider that when you turn 45, you may realize you have 20 more years of this shit job before you can retire.
Even with this strategy, you're not retiring at 45 unless you are frugal, have cheap hobbies, and never have kids or a non-working spouse. Also take care that you don't have any parents, siblings, or extended family that come to rely on you. Also don't forget expect to live anywhere even remotely expensive, unless you like camping.
You're not wrong, a family is more expensive. But if both parents pull the same (or similar) salary, it is enough to still retire at 45. Requires using more tax-advantaged plans to play for college, and may not work well in expensive cities.
Re: cheap hobbies, I used to date a public school teacher. She would save to go on guided trips to Antarctica, Peru, the Galapagos, New Zealand. You can live an amazing life if you plan for it.
The median household income in the US is $83,730 [1] - half of households are on less than that.
If you earn $100k and are willing to have the median lifestyle, and you can find a spouse that's willing, then the numbers work just fine.
Challenges include lifestyle inflation; housing costs if your six-figure job is in an expensive area; and finding a partner who's willing to be put in what is often a vulnerable and low-status position.
I don’t think these methods are possible anymore in this modern economy of “fire everyone because of AI and then rehire them a few months later at half the salary”.
If you’re not one of the senior managers, I don’t think these kinds of long term investments are feasible anymore.
I feel like this is a bit snarky, it simply means plan for your retirement and invest in your own future, take advantage of government / employer backed savings plans. Plenty of these exist over here. Don't waste your money.
Everything is not perfect in the singular country of Europe, I sure as hell don't want to be relying on only what the state decides it can give me in my old age.
they're pointing out that the US is insanely stupid when it comes to healthcare and retirement. the stuff we do in this country is so much extra work/effort/cost and all of it comes at the worker's cost.
My reading was that nothing of that applies in Europe. No earning 6 figures, no way to invest pre-tax or in any other tax advantaged way, no way to optimize healthcare costs, early retirement unlikely.
Retirement accounts are a thing in Europe though. In Poland for example there's IKE and IKZE. IKE is a bit simpler of the two. If you hold your money on IKE until you're 60 you're not paying taxes on that. Can invest in stocks or bonds.
This assumes a lot of things that may not be true and would not map to whatever mental model you formed with this.
People are often quick to dispense technically correct (or mostly correctly) financial advice but rarely is financial mangement simply a technical problem to be solved in someone’s life
> 2. Get an HSA and max that out. Invest it all in a target date retirement fund. Do not use any of it, pay for medical expenses with cash and save your receipts. Get reimbursed for the receipts when you retire.
Good advice on saving HSA reimbursements until later. Also, after 65 there's no penalty for withdrawing from your HSA; its just taxed at regular income at that point.
Ah yes, the good old US of A where a 23 year old can start out making $100k/yr.
While here I am, 39yo, having been in this field for 17 years and worked my way up to a lead, and having worked at banks, fintechs, medtechs and consultancies, am 'only' making roughly €76k/yr.
And this is with pouring personal time into studying and applying latest tech in side projects to stay relevant.
Honestly if the financials of the US tech scene ever normalize to what the rest of the world has, you guys are in for a rude awakening.
$1.8M-$2.2M. Assumes 6%-7.5% annual return. Does not include employer contribution. Provides $72k-$88k /yr income. Assuming you pull social security at 67, your continued gains exceed your draw, and your fund perpetuates until you die.
I would argue quite the contrary. NoSQL DBs got through their hype cycle and are now a standard part of stacks, but SQL (especially via Postgres) has re-emerged as the golden standard for the bulk of data needs.
Especially when companies over-provision their databases. Partially because the jump from cheap-ass to mid-tier is a massive increase in capacity.
Then you can offload stuff to the DB engine (as it should be), making everything more efficient, less data going between DB and App layers is good for everyone.
Also you get to do cool SQL shit nobody understands and you become invaluable =)
> Algorithms and data strictures are important — to a point. I don’t see pharmacist interviews test trivia about organic chemistry. There’s something fucked with our industry’s interview process.
Pharmacists have to get a special degree before they can even get an interview, and I've heard that the education is heavy on organic chemistry. Then you get a job as a cashier selling pills.
> Hacker news and r/programming is only good to get general ideas and keep up-to-date. The comments are almost worthless.
You got me.
> Once, someone asked me who I looked up to and I said Conan O’Brien [...]
He wrote for SNL and studied literature at Harvard, so there's probably plenty going on up there.
> on his last show on the Tonight Show, he told his audience to be kind and work hard
Conan really handled that disaster with tremendous grace and it paid immediate dividends. I can’t really think of a similar situation in popular culture. It is a good reminder of how to handle oneself especially during turmoil.
I did TDD properly the first time in my Masters Degree (ongoing). It was an eye-opener. Write your program in two different ways to make sure you know the requirements by making their outputs match. That's not me being snarky. It actually works well. Just make sure you can type quickly.
Sure, there are alcoholics in the past. But sitting with the intention of sounding drunk, interspersing deliberate typos with "pour another drink" and "take a sip" because someone thought that was a cool premise is weird.
It's one thing to write drunk, it's another thing to get drunk to write about being drunk
He wasn't drunken rambling though, he was getting drunk to do it. I think there's a real difference in message there - as much as it was probably fake.
"If you’re not sure what you want to do, just do Java. It’s a shitty programming language that’s good at almost everything."
- I agree, 100%.
And here's a take that a lot of the folks will disagree, and categorically state that these both belong to two entirely different domains: "Rust, is the evolution of Java. Not Kotlin, not Scala, not clojure, but, Rust".
The context dependency injection is so so so good. Once we switched over to json & Jax-rs, it made such a great simple direct backend. Good throughput. Just, a bit high memory.
Lost me at dynamic languages. Don't build anything of any significance in dynamic languages! ;)
Some good points. Laughed at TDD is a cult. I mean a lot of software orgs/cultures are cultish (Agile, Scrum, whatnot). At work I often feel I'm part of a cult.
On the contrary, I find "The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me." is exactly my sentiment too, with a caveat. I really like gradual typing, like python has. And not like ruby has (where it's either RBS files and it's tucked away, or it's sorbet and it's weird).
The worst code base I had to work in by far was a Python code base. Extremely difficult to refactor. Many bugs that were completely avoidable with static typing. I think maybe more modern Python is a little bit better but wouldn't be my choice for large projects. It's not just about correctness. It's also about performance. That code was so slow and that impacted our business.
One rebuttal to that is that with the benefit of hindsight, to a first approximation zero percent of the code I've written in my career turned out to be "of any significance" really.
Same. That line about "your legacy is your family and friends" hit hard.
I've been coding professionally for >30 years. I don't think any of my code has survived 5 years in production.
I don't think code quality affected that at all - I know the really, really, shitty code I wrote when learning OOP in the 90's survived for a looong time, while the amazing code I wrote for a startup 2018-2021 died with it.
One of the projects I'm most proud of is still running ten years later, and has processed over a billion AUD through it in that time, with very minimal maintenance. I recently consulted on it, and sure enough it's still ticking along nicely! The code is honestly quite good too, even if it is PHP (though in a very nice microframework we wrote on top of Silex: removed all magic that a lot of these systems relied on. No annotations!)
I haven't doing this forever (only 10+ years) but surprisingly I think a majority of what I've written is still running. Probably a fair bit will continue to run for a while yet too I think (again, surprising for CRUD web apps).
Most code I wrote over my career got pretty decent use and produced value for customers. Some was used by millions of people. What I work on today is used by thousands. It's important that it is of reasonable quality with less bugs, decent performance, functionality users are looking for etc.
A lot of code makes a difference but I guess there's a lot that doesn't?
I'd guess, on average, code I've written has a half-life of maybe 3 or 4 years. There's pretty much none of my code (with a few surprising exceptions) that's still been running or in production anywhere for more than 8 or 10 years.
At the time, a lot of it felt "important" and "significant". And some of it probably was at the time, to the businesses I wrote it for. But whether I sweated blood and tears to craft the most elegant and efficient software I was capable of, or I phoned it in and just copy/pasted Stack Overflow answers together until I met some interpretations of a requirement to be able to leave the office on time - really made no difference.
I've been pondering lately, thinking about GenAI and vibe coding, with the very real risk of creating completely unmaintainable codebases - whether that matters, if the code is likely to be retired or rewritten in 3-4 years anyway? My current gig is on to the 4th rewrite of it's web/mobile app backend platform in 15 years, which started out as a Groovy on Grails app, which got rewritten in Java, then rewritten again in Java, and now it's being rewritten in Python. Each rewrite had fairly good reasons at the time, but a huge amount of code here gets thrown away every 4 years or so - which looking back makes me seriously question whether any of it was "of any significance". To be honest, the 2026 Python code really isn't doing anything notably different or more complex than the Perl and JavaScript code I was writing in 1996 - web work is CRUD apps all the way down.
As a person who started in a dynamic language (PHP; don't laugh, it's actually really good for web dev) and worked in an infrastructure team which had to do a lot of refactoring... I can't agree with the sentiment either. Dynamic languages _look_ good, but lightly typed languages like Go strike a much better balance in my opinion
A lot of startups are cults. Tesla maybe the final form of a culted startup where the stock owners don't care about anything anymore.
That said, the people who change companies aren't the ones that believe that management ever had the best ideas, or are able to push back on the cult thinking with clarity. Unfortunately, though, it's not necessarily evidence that wins arguments, it's charisma, which is how the cult is started in the first place.
TDD is a cult. But knowing your pre-conditions an post-conditions for your isolated parts of your code is important. I think all your AI codegen will work better with this.
The entire AI ball of wax is built on python (dynamically typed) - or at least a large part of it. It probably needs to move to rust to save on power and compute cost.
The heavy lifting of AI is done by GPUs that are not running Python. But yes, a lot of orchestration and glue work is done by Python. Python can be a decent glue language and it has its place. But if the core/high performance logic of inference and training was written in Python then we wouldn't have today's AI. I imagine there are other languages in the mix.
Python is also the choice of non-programmers for simple work. Nothing wrong with that. But I wouldn't want e.g. my car's ABS system to be programmed in Python (or my browser or my OS or many other examples).
> But knowing your pre-conditions an post-conditions for your isolated parts of your code is important.
Design-by-Contract[0] is a formalization of this concept and well worth considering when working in code using mutable types. In addition to pre/post conditions, DbC also reifies class invariants (which transcend method definitions).
My biggest lessons I've learned as non-senior non-engineer:
1. You'll never be as smart as the smart guys. It's okay to give up.
2. Most likely you'll work with incompetent fools, get used to that.
3. Workplace is the best place to make friends. If someone tells you otherwise it's a psyop to turn you into a robot.
4. Minimize your output while trying to maximize your salary because mythical "job satisfaction" doesn't exist and it makes much more sense to redirect your energy elsewhere.
5. Luck is the most important factor.
There is nothing I've done at work I'm truly proud of. Everything I'm proud of is completely unrelated to work.
> The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there’s any recommendations, I’d seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)
Good docs are docs that make it easy to implement the next feature.
From an AI perspective, it's my observation that LLMs often write code with lower quantity / quality docs. At the same time, they are reasonably good at synthesizing / inferring meaning from code that lacks good docs. They often do so internally by forming a chain of thought / reasoning around how the code works. The docs that should be written as part of the code are probably the same things that an LLM would reasonably come to by spending tokens when modifying that code. I believe that this should be trained into model so that future LLM work starts with not having to build up context.
In the absence of that being built in, something I've been experimenting a little with is tuning what I want to see in docs that actually help source control / development. Currently that's at https://github.com/joshka/skills/tree/main/doc-steward - still needs a bunch of work, but it's generally better than nothing. YMMV
This genuinely looks like that I wrote it...until I saw that LISP line, definitely not me. But do agree with a lot of items in the list, and I happen to be a DE, too.
I am a big fan of learning LISP, at least once. Going through SICP after more than a decade of writing code for a living was probably the single best thing I did to deepen my understanding of a lot of compsci concepts, data structures, and how to think about software. For me, at least, it was very much a seeing the matrix for the first time kind of moment. My LISP use has quickly declined, but I've dabbled in dozens of programming languages since then, and I do attribute not feeling lost to that experience.
> The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there’s any recommendations, I’d seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)
> A lot of progressive companies, especially startups, talk about bringing your “authentic self”. Well what if your authentic self is all about watching porn? Yeah, it’s healthy to keep a barrier between your work and personal life.
this is probably the best truth. after a while it's easy to recognize people that are consistently being their "authentic self" and they're usually the worst.
"HR" does not set your professional obligations. If you need to be drunk to talk this honestly, you are not a "senior" nor a mentor, but an incipient alcoholic and a coward.
Then again, this person is obviously also lying to claim the engineer title - sit down, "data science!" You're only even here because Product prefers being lied to - so that really sets an ironically honest baseline on how seriously anyone should be taking any of this farrago.
For a drunk post it's damn long!
> You know what the best part of being a software engineer is? You can meet and talk to people who think like you. Not necessarily the same interests like sports and TV shows and stuff. But they think about problems the same way you think of them. That’s pretty cool.
That hasn't really been my experience, for every 50 people I meet maybe 1 is here for the craft, the rest want to do 9-5, have a visibility at work, work on impactful projects but actually talk about their problems, their opinions in a deeper way - almost never.
> The most underrated skill to learn as an engineer is how to document.
Document why. I can read code. I want to know _why_ this nebulous function called "invert_parameters" that is 200 lines long even exists. Which problem did you have that this function solved? Why was this problem there in the first place? Write some opinions on maybe its intended lifetime of the codebase. Hell, I write comments that apologize, just so that a future reader knows that the code I wrote wasn't meant to be great but that I was in a time crunch or a manager was breathing down my neck, or that some insane downstream/upstream thing did something... well, insane.
Paint some picture of your mindset when writing something, especially if it's non-obvious, as that'll give all the additional context not captured in code, when reading the code.
Obviously this isn't the only good documentation rule, but I wish people - juniors and seniors alike - would do this more often, especially at the workplace.
Sadly I have rarely seen people doing this. These shadow knowledge usually went away with their owners when they left the company, left other people scratching their heads.
“a new job in two weeks.” heh, yeah everyone was opining expertise back then when employees had control of the market.
What are you quoting, because I can't find that text in the article!?
The two weeks reference was in the reddit post the blog post linked to.
https://www.reddit.com/r/ExperiencedDevs/comments/nmodyl/dru...
> He fire me? I'll just pick up a new job in 2 weeks.
And... yeah... the reddit post is from 5 years ago when the job market was very, very different.
It was about getting fired (your manager stuff) and then moving to another job very shortly afterwards (the two weeks is correct)
> Don’t meet your heroes. I paid 5k to take a course by one of my heroes. He’s a brilliant man, but at the end of it I realized that he’s making it up as he goes along like the rest of us.
Ha yup - I've felt this one before :D
As a child and adolescent I always imagined that something would click when I became an adult and I would become good at things and understand the world. That never happened, and then I realised it never happens for anyone. We're all just large children walking around figuring things out. Some of us figure things out faster, some of us stop trying to figure things out, but we're all just as clueless in the grand scheme of things. It's a miracle and a testament to our perseverance and ambition that things still work as well as they do.
On the other hand, I've contacted several of my heroes (not been able to meet as many of them in person) and that's always been an exhilerating, formative experience. I strongly recommend it if you can think of a good reason. (I have a list of heroes I have yet to reach out to because I haven't yet encountered an interesting enough problem to offer them. Several of them unfortunately have an actuarial deadline not too far into the future.)
I once worked with someone well renowned in my circles who gave talks, ran a blog, was cited/edited other peoples books.
His code did not match the hype, to say the least. His SDLC even less so.
There is probably an ego associated with being renowned that doesn't align with team-based work. He likened basic things like code reviews or PRs to being brought before The Hague and that the rest of the team was a bunch of bureaucrats.
everyone is guessing
some are just a bit better at guessing
I am not sure which profession they are in (software development?), but no. Not everybody is guessing. If they were you would have half of the buildings and bridges collapsing and the other half on fire by bad electrical wiring.
You can legitly learn how to do things properly and people who learnt to do that do the polar opposite of guessing. It is just that the world of software development has yet to be made liable for their results in the same way as civil or electrical engineers. So in software development many are just guessing because guessing wrong won't ruin their life.
"Work from home is the tits. But lack of whiteboarding sucks."
Literally the only thing I miss
“Hacker news and r/programming is only good to get general ideas and keep up-to-date. The comments are almost worthless.” In full effect as per usual.
Dan Luu has an amazing collection of great comments from HN that are worth the read: https://danluu.com/hn-comments/
Reading all the Sam Altman glazing from 10 years ago, knowing what i know now...
Quite a few major issues with the post:
IMO drinking is a very personal thing so I almost always drank solo. Like playing piano — I always thought playing in public very weird, almost equaling naked in public…
>Lots of posts (e.g. Apple CEO change) had tons of useless stuff
Funny to read from someone else who noticed :) maybe broad appeal of the topic had a big impact
POV you don't live anywhere near Sonoma.
your comment on drinks is odd.
their comments on HN comments is funny as well in light of the original claim
Tongue-in-cheek
> Hacker news and r/programming is only good to get general ideas and keep up-to-date. The comments are almost worthless.
> Max out our 401ks
If there's any 20-somethings here that make 6 figures, listen carefully:
If you start when you're 23, and you make $100k/yr, you can retire at 45. That may sound very old right now, and you might think, I'll just save later. But consider that when you turn 45, you may realize you have 20 more years of this shit job before you can retire.Even with this strategy, you're not retiring at 45 unless you are frugal, have cheap hobbies, and never have kids or a non-working spouse. Also take care that you don't have any parents, siblings, or extended family that come to rely on you. Also don't forget expect to live anywhere even remotely expensive, unless you like camping.
You're not wrong, a family is more expensive. But if both parents pull the same (or similar) salary, it is enough to still retire at 45. Requires using more tax-advantaged plans to play for college, and may not work well in expensive cities.
Re: cheap hobbies, I used to date a public school teacher. She would save to go on guided trips to Antarctica, Peru, the Galapagos, New Zealand. You can live an amazing life if you plan for it.
> non-working spouse
Does that mystical creature still exist? Or is it perhaps more likely if one of the pair has a high yield income?
The median household income in the US is $83,730 [1] - half of households are on less than that.
If you earn $100k and are willing to have the median lifestyle, and you can find a spouse that's willing, then the numbers work just fine.
Challenges include lifestyle inflation; housing costs if your six-figure job is in an expensive area; and finding a partner who's willing to be put in what is often a vulnerable and low-status position.
[1] https://fred.stlouisfed.org/series/MEHOINUSA672N
Not sure why this was downvoted; it doesn't say you shouldn't do all those things, only that they're no guarantee you'll be able to retire at 45.
I don’t think these methods are possible anymore in this modern economy of “fire everyone because of AI and then rehire them a few months later at half the salary”.
If you’re not one of the senior managers, I don’t think these kinds of long term investments are feasible anymore.
What does any of this mean? Greetings from Europe.
I feel like this is a bit snarky, it simply means plan for your retirement and invest in your own future, take advantage of government / employer backed savings plans. Plenty of these exist over here. Don't waste your money.
Everything is not perfect in the singular country of Europe, I sure as hell don't want to be relying on only what the state decides it can give me in my old age.
Save money for retirement early
Retirement and health savings accounts.
they're pointing out that the US is insanely stupid when it comes to healthcare and retirement. the stuff we do in this country is so much extra work/effort/cost and all of it comes at the worker's cost.
they were being sarcastic.
My reading was that nothing of that applies in Europe. No earning 6 figures, no way to invest pre-tax or in any other tax advantaged way, no way to optimize healthcare costs, early retirement unlikely.
Retirement accounts are a thing in Europe though. In Poland for example there's IKE and IKZE. IKE is a bit simpler of the two. If you hold your money on IKE until you're 60 you're not paying taxes on that. Can invest in stocks or bonds.
Yes, as always it depends on the country. Germany and a bunch of others have nothing except completely useless insurance/capital guaranteed options.
For investments, you invest post-tax and pay capital gains when withdrawing.
Or, very smart for the establishment.
> the stuff we do in this country is so much extra work/effort/cost and all of it comes at the worker's cost.
The GP described tax optimizations for the highest earners. The idea that they would be better off in Europe is plainly ridiculous.
This assumes a lot of things that may not be true and would not map to whatever mental model you formed with this.
People are often quick to dispense technically correct (or mostly correctly) financial advice but rarely is financial mangement simply a technical problem to be solved in someone’s life
> 2. Get an HSA and max that out. Invest it all in a target date retirement fund. Do not use any of it, pay for medical expenses with cash and save your receipts. Get reimbursed for the receipts when you retire.
Very important detail, FSA is not HSA lol.
It's incredible how out of touch this place is sometimes.
Good advice on saving HSA reimbursements until later. Also, after 65 there's no penalty for withdrawing from your HSA; its just taxed at regular income at that point.
Ah yes, the good old US of A where a 23 year old can start out making $100k/yr.
While here I am, 39yo, having been in this field for 17 years and worked my way up to a lead, and having worked at banks, fintechs, medtechs and consultancies, am 'only' making roughly €76k/yr.
And this is with pouring personal time into studying and applying latest tech in side projects to stay relevant.
Honestly if the financials of the US tech scene ever normalize to what the rest of the world has, you guys are in for a rude awakening.
It's an outlier, even in America. I live in the US and no 23 year olds at my company are making 100k/year, lol.
Most jrs in America are working jobs like this - https://www.indeed.com/viewjob?jk=0dcd3d05ab694ba8
And this will get you like $1M at 45? You can’t retire on that.
$1.8M-$2.2M. Assumes 6%-7.5% annual return. Does not include employer contribution. Provides $72k-$88k /yr income. Assuming you pull social security at 67, your continued gains exceed your draw, and your fund perpetuates until you die.
If you retire at 45 won't that significantly impact social security?
You can't live on $40,000 a year?
What about property taxes, the occasional $40k visit to the ER for a few stitches?
Does that happen often to you?
> Get reimbursed for the receipts when you retire.
Holy crap, you can do this? I always assumed for some reason you had to pay for expenses with an HSA in the year they were incurred.
That's for an FSA (which is similar to but distinct from an HSA).
Wow, this is 2021? Feels like 2014. SQL, getting a new job in 2 weeks, etc.
Has SQL somehow become less relevant?
I would argue quite the contrary. NoSQL DBs got through their hype cycle and are now a standard part of stacks, but SQL (especially via Postgres) has re-emerged as the golden standard for the bulk of data needs.
Especially when companies over-provision their databases. Partially because the jump from cheap-ass to mid-tier is a massive increase in capacity.
Then you can offload stuff to the DB engine (as it should be), making everything more efficient, less data going between DB and App layers is good for everyone.
Also you get to do cool SQL shit nobody understands and you become invaluable =)
> Algorithms and data strictures are important — to a point. I don’t see pharmacist interviews test trivia about organic chemistry. There’s something fucked with our industry’s interview process.
Pharmacists have to get a special degree before they can even get an interview, and I've heard that the education is heavy on organic chemistry. Then you get a job as a cashier selling pills.
> Hacker news and r/programming is only good to get general ideas and keep up-to-date. The comments are almost worthless.
You got me.
> Once, someone asked me who I looked up to and I said Conan O’Brien [...]
He wrote for SNL and studied literature at Harvard, so there's probably plenty going on up there.
> on his last show on the Tonight Show, he told his audience to be kind and work hard
Conan really handled that disaster with tremendous grace and it paid immediate dividends. I can’t really think of a similar situation in popular culture. It is a good reminder of how to handle oneself especially during turmoil.
Related:
Drunk Post: Things I've Learned as a Sr Engineer - https://news.ycombinator.com/item?id=27333260 - May 2021 (494 comments)
I did TDD properly the first time in my Masters Degree (ongoing). It was an eye-opener. Write your program in two different ways to make sure you know the requirements by making their outputs match. That's not me being snarky. It actually works well. Just make sure you can type quickly.
I feel strange about someone deciding an interesting use of their time is getting drunk alone to write a blog post.
You thought that was real? I assumed it was a literary device. This wasn’t journalism.
Getting drunk and reflecting on one's life is not that uncommon
Wait until you hear about Bukowski, Faulkner or Kerouac.
Sure, there are alcoholics in the past. But sitting with the intention of sounding drunk, interspersing deliberate typos with "pour another drink" and "take a sip" because someone thought that was a cool premise is weird.
It's one thing to write drunk, it's another thing to get drunk to write about being drunk
> It's one thing to write drunk, it's another thing to get drunk to write about being drunk
I would again see Bukowski.
Is Bukowski generally seen as a role model?
I don't think the dude drunken rambling on reddit was aspiring to be a role model, just share what he perceived as wisdom he's gained in life.
He wasn't drunken rambling though, he was getting drunk to do it. I think there's a real difference in message there - as much as it was probably fake.
I'm not sure I follow, what's the difference in message between drunken rambling and, getting drunk and rambling?
He's certainly more famous that most HN posters :)
Perhaps he also had fun doing it.
"If you’re not sure what you want to do, just do Java. It’s a shitty programming language that’s good at almost everything."
- I agree, 100%.
And here's a take that a lot of the folks will disagree, and categorically state that these both belong to two entirely different domains: "Rust, is the evolution of Java. Not Kotlin, not Scala, not clojure, but, Rust".
I feel like Go has a similar role to Java. Although it's mercifully free of inheritance and the functional stuff they've bolted on.
Rust has a similar role to C++ but reads more like Python and Elixir's lovechild.
Yeah Go is a new Java essentially. Also arguably it's a much better alternative because of static linking and no JIT
The context dependency injection is so so so good. Once we switched over to json & Jax-rs, it made such a great simple direct backend. Good throughput. Just, a bit high memory.
Lost me at dynamic languages. Don't build anything of any significance in dynamic languages! ;)
Some good points. Laughed at TDD is a cult. I mean a lot of software orgs/cultures are cultish (Agile, Scrum, whatnot). At work I often feel I'm part of a cult.
On the contrary, I find "The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me." is exactly my sentiment too, with a caveat. I really like gradual typing, like python has. And not like ruby has (where it's either RBS files and it's tucked away, or it's sorbet and it's weird).
The worst code base I had to work in by far was a Python code base. Extremely difficult to refactor. Many bugs that were completely avoidable with static typing. I think maybe more modern Python is a little bit better but wouldn't be my choice for large projects. It's not just about correctness. It's also about performance. That code was so slow and that impacted our business.
Refactoring is a young mans game. I either nuke it and start over or treat it as a black box.
You can just as easily take a static language dynamic - in userland.
I've interop'd with JS from Haskell and you can just go full dynamic property access. And gradually add phantom typed APIs around it.
Debugging Haskell and JS in the same stack? You kids are brave. And/or I'm a coward and a simpleton.
I debug in ghci mostly
console.log also still works fine
One rebuttal to that is that with the benefit of hindsight, to a first approximation zero percent of the code I've written in my career turned out to be "of any significance" really.
Same. That line about "your legacy is your family and friends" hit hard.
I've been coding professionally for >30 years. I don't think any of my code has survived 5 years in production.
I don't think code quality affected that at all - I know the really, really, shitty code I wrote when learning OOP in the 90's survived for a looong time, while the amazing code I wrote for a startup 2018-2021 died with it.
One of the projects I'm most proud of is still running ten years later, and has processed over a billion AUD through it in that time, with very minimal maintenance. I recently consulted on it, and sure enough it's still ticking along nicely! The code is honestly quite good too, even if it is PHP (though in a very nice microframework we wrote on top of Silex: removed all magic that a lot of these systems relied on. No annotations!)
I haven't doing this forever (only 10+ years) but surprisingly I think a majority of what I've written is still running. Probably a fair bit will continue to run for a while yet too I think (again, surprising for CRUD web apps).
Most code I wrote over my career got pretty decent use and produced value for customers. Some was used by millions of people. What I work on today is used by thousands. It's important that it is of reasonable quality with less bugs, decent performance, functionality users are looking for etc.
A lot of code makes a difference but I guess there's a lot that doesn't?
Please elaborate
I'd guess, on average, code I've written has a half-life of maybe 3 or 4 years. There's pretty much none of my code (with a few surprising exceptions) that's still been running or in production anywhere for more than 8 or 10 years.
At the time, a lot of it felt "important" and "significant". And some of it probably was at the time, to the businesses I wrote it for. But whether I sweated blood and tears to craft the most elegant and efficient software I was capable of, or I phoned it in and just copy/pasted Stack Overflow answers together until I met some interpretations of a requirement to be able to leave the office on time - really made no difference.
I've been pondering lately, thinking about GenAI and vibe coding, with the very real risk of creating completely unmaintainable codebases - whether that matters, if the code is likely to be retired or rewritten in 3-4 years anyway? My current gig is on to the 4th rewrite of it's web/mobile app backend platform in 15 years, which started out as a Groovy on Grails app, which got rewritten in Java, then rewritten again in Java, and now it's being rewritten in Python. Each rewrite had fairly good reasons at the time, but a huge amount of code here gets thrown away every 4 years or so - which looking back makes me seriously question whether any of it was "of any significance". To be honest, the 2026 Python code really isn't doing anything notably different or more complex than the Perl and JavaScript code I was writing in 1996 - web work is CRUD apps all the way down.
As a person who started in a dynamic language (PHP; don't laugh, it's actually really good for web dev) and worked in an infrastructure team which had to do a lot of refactoring... I can't agree with the sentiment either. Dynamic languages _look_ good, but lightly typed languages like Go strike a much better balance in my opinion
A lot of startups are cults. Tesla maybe the final form of a culted startup where the stock owners don't care about anything anymore.
That said, the people who change companies aren't the ones that believe that management ever had the best ideas, or are able to push back on the cult thinking with clarity. Unfortunately, though, it's not necessarily evidence that wins arguments, it's charisma, which is how the cult is started in the first place.
TDD is a cult. But knowing your pre-conditions an post-conditions for your isolated parts of your code is important. I think all your AI codegen will work better with this.
The entire AI ball of wax is built on python (dynamically typed) - or at least a large part of it. It probably needs to move to rust to save on power and compute cost.
The heavy lifting of AI is done by GPUs that are not running Python. But yes, a lot of orchestration and glue work is done by Python. Python can be a decent glue language and it has its place. But if the core/high performance logic of inference and training was written in Python then we wouldn't have today's AI. I imagine there are other languages in the mix.
Python is also the choice of non-programmers for simple work. Nothing wrong with that. But I wouldn't want e.g. my car's ABS system to be programmed in Python (or my browser or my OS or many other examples).
> But knowing your pre-conditions an post-conditions for your isolated parts of your code is important.
Design-by-Contract[0] is a formalization of this concept and well worth considering when working in code using mutable types. In addition to pre/post conditions, DbC also reifies class invariants (which transcend method definitions).
0 - https://en.wikipedia.org/wiki/Design_by_contract
Me? not much. Ive learned more in the streets...
My biggest lessons I've learned as non-senior non-engineer:
1. You'll never be as smart as the smart guys. It's okay to give up.
2. Most likely you'll work with incompetent fools, get used to that.
3. Workplace is the best place to make friends. If someone tells you otherwise it's a psyop to turn you into a robot.
4. Minimize your output while trying to maximize your salary because mythical "job satisfaction" doesn't exist and it makes much more sense to redirect your energy elsewhere.
5. Luck is the most important factor.
There is nothing I've done at work I'm truly proud of. Everything I'm proud of is completely unrelated to work.
> What’s the worse that can happen? He fire me? I’ll just pick up a new job in 2 weeks.
That did not age well.
> The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there’s any recommendations, I’d seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)
Good docs are docs that make it easy to implement the next feature.
From an AI perspective, it's my observation that LLMs often write code with lower quantity / quality docs. At the same time, they are reasonably good at synthesizing / inferring meaning from code that lacks good docs. They often do so internally by forming a chain of thought / reasoning around how the code works. The docs that should be written as part of the code are probably the same things that an LLM would reasonably come to by spending tokens when modifying that code. I believe that this should be trained into model so that future LLM work starts with not having to build up context.
In the absence of that being built in, something I've been experimenting a little with is tuning what I want to see in docs that actually help source control / development. Currently that's at https://github.com/joshka/skills/tree/main/doc-steward - still needs a bunch of work, but it's generally better than nothing. YMMV
This genuinely looks like that I wrote it...until I saw that LISP line, definitely not me. But do agree with a lot of items in the list, and I happen to be a DE, too.
I am a big fan of learning LISP, at least once. Going through SICP after more than a decade of writing code for a living was probably the single best thing I did to deepen my understanding of a lot of compsci concepts, data structures, and how to think about software. For me, at least, it was very much a seeing the matrix for the first time kind of moment. My LISP use has quickly declined, but I've dabbled in dozens of programming languages since then, and I do attribute not feeling lost to that experience.
> The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there’s any recommendations, I’d seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)
Just wait till he hears about Claude Code
> A lot of progressive companies, especially startups, talk about bringing your “authentic self”. Well what if your authentic self is all about watching porn? Yeah, it’s healthy to keep a barrier between your work and personal life.
this is probably the best truth. after a while it's easy to recognize people that are consistently being their "authentic self" and they're usually the worst.
FFS, be professional at work.
"HR" does not set your professional obligations. If you need to be drunk to talk this honestly, you are not a "senior" nor a mentor, but an incipient alcoholic and a coward.
Then again, this person is obviously also lying to claim the engineer title - sit down, "data science!" You're only even here because Product prefers being lied to - so that really sets an ironically honest baseline on how seriously anyone should be taking any of this farrago.