Things I Wish I’d Learned Sooner After Being a Developer for 10 Years | Hacker News Reader

Things I Wish I’d Learned Sooner After Being a Developer for 10 Years

medium.com

An observation: a lot of these---especially 'soft skills'---can't be properly learned earlier. They're a side effect of experience, and the 10 years doing the job is the only way to properly get them. The things I most often hear from potential employers when we ask what we should focus on more in teaching them are "soft skills" and "troubleshooting". My response is now to ask which of the long list of technical skills we teach we should drop or reduce in favour of more soft skills (none) and to remind them that when they say they need employees who are good with team-mates and clients and good troubleshooters, what they're describing is an employee with experience and I simply can't generate that in a two-year program. Fundamentally, that part of the education is the on-the-job part, and it can't be skipped.

We do work at those, but fundamentally, skills at (1) working well with a variety of people and (2) understanding systems and their interactions well enough to hypothesize and test for causes of faults are both things you can have more or less talent in, but they're fundamentally skills that come as the result of substantial experience working with different people and working with complicated systems.

You probably can't properly learn these without spending the ten years, but you can choose jobs and colleagues and experiences that will help you learn them better. Better to focus on emulating how people learned these skills than trying to skip the hard part.

This is the good type of soft skill, and there is the bad type: soft skill when a person can just talk very nicely, and suck it up to his upper management, do the very simple things (like fixing all lint errors and following 30 other recommendations inside the company) instead of providing real value to the company and the users to get promoted.

I had a manager like that, and I made the mistake of confronting him for ,,safe'' and bad technical decisions (in which case the higher level person always wins), instead of just nicely switch teams without confrontation.

An aphorism I occasionally use (I can be tedious): "the only way to make a twenty-year old comfortable leading a meeting is to wait until they're a thirty-year old." Doesn't stop us from forcing the poor bastards to do public-speaking assignments or dropping them into "teams" of completely inexperienced people they've never met with no leaders in the name of ephemeral "soft-skills."

I am only 26, and I know I'm not good at management, but I don't think that's really true. During secondary school, I took part in Model United Nations conferences, and after the first two or three, I was magically completely happy standing up in front of a large audience of peers being asked awkward questions. There are a bunch of required skills that you can simply train (e.g. with Toastmasters), even if you can't hit the entire spectrum of management skill this way.

That's a fair point, but note that you're describing the sort of experience that is real, and therefore valuable. Model United Nations is one thing, 'give a two minute speech on a topic of your choice, and we're going to grade your slide deck' is another. Extra-curricular things like toastmasters and Model UN and things like apprenticeships, internships and co-op are ways of acquiring more real experience earlier, not a replacement for real experience. Sadly, programs that provide that sort of experience are among the first casualties of budget or other pressures.

I was active in Model UN many years ago, and I really just didn’t get Toastmasters. It felt like talking about nothing for no reason to people that don’t care. It’s unfortunate that meaningful formal debate seems to stop in adulthood. There certainly are plenty of things to disagree about.

There should be a topic-specific analogue of Toastmasters and it shouldn't urge you to exude false confidence.

This is such a self-fulfilling prophecy it hurts. Especially having been in leadership programs with other engineers in my early 20’s and go on to see them have some of the best soft skills in my later years. After 3 Fortune 100 companies, I have met a magnitude more of software engineers and infrastructure engineers over 40 that refuse to speak up and refuse lead because they see same thing over and over again, new older leadership comes in tries to change things a bit, they just keep developing software, and question why does it matter to lead or communicate.

I currently work on a team of 10 engineers and 2 of them over 50, asked me what was GraphQL, when I did a public demo on GraphQL APIs around it. We are in a department that runs an e-commerce product with 30mil+ monthly visitors. How does a 25, 26, 27, year old automatically mean bad at public speaking...? Personally, my best manager has be 28 years old.

The numbers are arbitrary. My primary point is that many important skills cannot be learned without the requisite experience. Individual experiences, talents and interests vary. Perhaps adjust my crude analogy to note that your very good manager at 28 would probably agree that she wasn't very good at it when she first left school or for the first few years of her career, and that her skill at working with other people was learned primarily from working with other people, not self-study, instruction, or other process that allowed for much compression of the time it takes. Those who excel early usually have done so because they started earlier and sought more opportunities for the necessary experience. I suspect if you broke it down to hours, you'd find a similar number, just applied at a rate of 20 hours a week instead of 10.

I should add that there is one other way to make that twenty-year-old comfortable: have them be a sociopath. But our problem of distinguishing between sociopathy and confident leadership is a much, much longer conversation.

I would add that part of that experience is seeing how teams/situations/products pan out and then being able to recognize those patterns and nudge/head off issues early in the process.

In that respect I've learned a lot more from projects that have gone off the rails to some degree than projects where everything went according to plan.

In an ideal world you have the opportunity to give each person on the team the right amount of risk with enough of a safety net so that if things really go sideways the team has their back. Finding the balance with the rest of the project requirements, business inputs and other pieces is where it gets interesting.

Failure is our best teacher. I do spend a lot of time on that with my students. I have a professional and personal interest in formal failure analysis, and try to instill that in students. Apollo 1 saved more lives than it took, and Windows Vista teaches you everything you need to know about monolithic, slow-moving software projects with unclear goals. Dai-Katana and Duke Nukem are masters' courses in the toxic interaction of aggressive marketing and product development. I think Trump might end up being one of the best things that ever happened to American Democracy.

I think they can be taught. By setting out to teach rather than boast about experience, ive seen senior developers instilling better soft-skills in new grads. A lot of new grads just aren't thinking about this stuff as much as the tech but once you take them under your wing and walk them through how the presentation of an idea will let it be received better regardless of technical merit they begin to see it.

It may take 10 years to blindly learn these skills but with a single, good mentor you can learn it quickly. I think most senior developers dont have the patience nor the transparency to lay this out though. Its a very honest conversation to have with someone - "Hey that idea you had is a good one but your presentation of it is problematic. Here is how you can make people more likely to see your point of view" is not as sexy as debating microservice vs monolith.

I would argue: There is NO shortcut for experience. But not all experience is created equal. Telling someone HOW to do things right (we are talking soft skills, for hard skills its a bit different), is not helpful. You need to expose them to situations where they have weaknesses, and then coach them how to overcome the problems they face. I.e. there is a fine line between "telling people what to do", which is ineffective short-term and contraproductive long-term; and "exposing people to situations that make them behave wrong", which is the most effective learning tool, that doesn't have drawbacks, outside of the short-term (because you know that this person will not do the job right, but you also know they are not going to do it wrong another time, plus they will learn how to recognize other similar situations and avoid making this mistake there as well).

The best thing universities can do is to instill an understanding of soft skills in people. They should come out of university knowing:

* How important soft skills are

* That they are the differentiator between senior and junior

* How to best learn them (don't hunt highest pay, hunt highest experience gain)

* etc.

As a counter observation: I agree with you but I don’t think it takes 10 years, but it’s not a bad estimate. Being deeply involved in teams working important products for your company can speed this up.

Agreed. I allude to that in my last sentence of the original comment.

Off-topic comment: I was having some trouble understanding the text. The author would start explaining some advice and I didn’t know which advice he was referring to. Like ”This is one I struggle with the most”, “this” what? I would go back to the previous paragraph and there was no reference, worst, apparently it was another topic!

Then it hit me, the images with words on it every few paragraphs were the pieces of advice! They were not ads or merely unimportant illustrations, they were the titles! I unconsciously ignored them all on first read, banner-blindness or something like that.

I actually scanned the post for bullet points the moment I opened the page and couldn’t find them. Because the bullet points were designed as images.

Important to notice that now, looking at them as bullet points, I like the design. They useful mini-posters. But they had this side-effect on me of magically becoming invisible.

I had exactly the same problem, I was trying to scan for the titles and was confused I didn't find any title and TBH a bit annoyed at how many "ads" there were getting in the way of finding the important information.

This is called the banner blindness effect: https://en.wikipedia.org/wiki/Banner_blindness

Not medium link: https://alexlakatos.com/coding/2020/11/17/ten-things-learned...

@dang could we swap this link for the medium one? its faster and no login wall

> "Sure, I could make an extra 10% every year, but would that make me happier than working from home, on my own terms?"

If it allows you to provide more ('stuff', or security, or stability) for a family, then yes, it might make you happier.

I read articles like this and they mostly tend to be from the perspective of younger people and/or folks without families to support.

An extra 10% pay increase, over just a few years, provides more general savings, perhaps buys solid life insurance, helps pad savings for future education, or moving expenses to fund a job/life change, etc.

Another nugget - "Know your worth". It's not bad advice, but something the author didn't mention was understanding how your worth is determined. You can do the exact same work for company A and company B. Company A may be able to extract huge value from your work, and company B may struggle to keep the lights on. When working for someone else, "your worth" is directly related to how capable they are at operating their business profitably.

I've no doubt the author's views work for him, and probably many people like him, but as with most posts like this, they're not universal.

As someone with a family, my preference is that I can work from home to be around my family more. I feel this is more valuable to them than some more money in our savings account but that’s just me. To each their own!

Had a colleague die a few years ago. He'd lost some project work, and let his life insurance lapse. Had a heart attack just a few weeks later, and left a wife and 3 kids with very little. He worked from home and spent time with them, but had hit a point where money was a problem. The story sticks with me because he'd contacted me just a couple months before he died asking if I had any work/referrals, and I had nothing at that time.

The older I get, the more I see less the great outcomes when adversity hit people I know (whether death or illness or some other big hit). Money isn't everything, but in many of those cases, having an extra $k saved up would indeed help smooth people through those rough patches. I'm actually amazed at how many folks work for decades, then something happens, and there's a gofundme set up for the family to help with day to day bills.

If you have all your financial ducks in a row, everyone is comfortable, and you have the life you want, that's great. To each their own, indeed! :)

Well everyone would agree that generally more income is good. But cutting 10-20% on your income for a better job in terms of work life balance, interest or whatever else could be worth it for many people. Is there really that much difference between someone making 80K and someone making 100K? In a country like the U.S, where you can potentially lose your health insurance and sending your kids to college is super expensive - then maybe. In Europe the difference is gonna be only what kind of car you drive and how big your house is. In terms of your health, your kids opportunities in life etc, it doesn't matter that much.

> I'm actually amazed at how many folks work for decades, then something happens, and there's a gofundme set up for the family to help with day to day bills.

Not to go all Bernie Sanders on you, but... welcome to America?

Maybe you don't live in the US. But here in the US, a single medical bill can wipe you out. And because we value free market healthcare, that means you don't know what the price will be until after you receive treatment. You won't know if you're covered or denied coverage until after the incident. Because that's how the Free Market(tm) works.

Be thankful if you've never had the luxury of spending months battling a massive bill you received because one of the ten random people you saw one night in a hospital was out-of-network despite being at an in-network hospital.

You don't have to be a full blown socialist to see how fucked America is.

I do live in America, and possibly should have qualified that statement. The folks I was referring to were already ... middle class or higher, who understood the value of savings/insurance, and had ample opportunity to do so, and still didn't. That's what sort of... gets me. Situations where people were never earning enough to be able to remotely prepare for financial setbacks... I don't include them in my "amazement" comment. I'm generally "amazed" they manage to survive at all in today's world.

I've not quite had the situation you've mentioned with medical stuff, but have had some ER visits which end up costing thousands out of pocket on top of the ~$10k/year we spend on insurance.

For people I've known who were in software, or engineering, or law, and had high-paying careers over decades, to know they were still living that close to the edge financially, that's what amazes me. And sometimes it's bad spending habits (or drugs, or whatever), sometimes it's just poor financial education.

But to the original point - an extra ~10% year in income to many folks - even if it means a slightly reduced 'quality of life' by some measure - can have an impact on their lives down the road, but they also need to manage that extra income properly.

US health care does not even resemble a free market system. Every incentive is perverted by the government, starting with the tax code practically forcing insurance to be tied to employers.

You can also get a smaller house/Apartment, which young kids probably won’t mind, and have the less paying job that allows you more tone with family. That may also reduce the chance of heart attack, btw.

Hmm 10% sounds quite negligible in terms of security/stability etc. Way more important, for you and your family, to be happy with your work than to provide 10% more income imo.

Good read, especially the part about soft skills. Sometimes it seems to me like it's almost impossible to change them. It's "easy" to learn something hard and defined, like coding. But changing how you communicate? How you react to conflict? Your body language? It's even harder if you're trying to change these soft behaviors of someone else, like a partner.

Not sure what the takeaway is here, just wanted to express my thoughts on it. Soft behaviors seem both like some enormous formless cloud that you can't really define and a rock-solid mountain you have little hope of moving.

Also, reading this on his own website instead of on medium is a much better experience, definitely recommend.

Just get a controlling gf/bf who will tirelessly analyze your verbal and non-verbal communication. Soon you will be very aware of any weak areas in your communication and conflict management.

Pick one reaction you consistently have that you want to change.

Every time you have the “wrong” action think about the “right” reaction. Over years your “natural” reaction will change.

Get a coach, worked for me.

> “ Don’t like your new boss? Just quit. Enough people do it, and their boss will fix it. You don’t like your company’s policies around privacy, diversity, inclusion, human rights? Quit.”

This is psycho advice. It ranks up there with the crazy myths about just being able to instantly get new software jobs (when the actual time of job searches is usually longer than 6 months, despite the tone deaf wave of gainsaying comments this is sure to incite).

Voting with your feet rarely leads to organizational changes, especially if you don’t give clear feedback or spend sincere effort trying to fix the issues you’re having prior to quitting. More likely, you quitting is just tacitly reinforcing power and control by the shitty people who made your experience shitty.

When you need to quit, by all means, absolutely do it. But don’t kid yourself that there’s any “voting” going on. Do yourself and others a favor: give feedback and take responsibility for your own job satisfaction. Nobody can help you if you won’t try to get help.

And don’t count on a fast job search. This topic is so tone dead on HN. Some cacophony of commenters will swear you can get a million jobs from all your spam LinkedIn headhunters and be re-employed in weeks, but it is emphatically not true and the selection bias of those examples has to imply just ignoring them as inapplicable to the vast majority of software engineers. Interview prep, finding a good fit and getting what you want in a position and in compensation is really hard and takes a long time in software.

recruiter: based on your impressive linkedin profile, I think you'd be a great fit for a full-stack role with my client! let me know if you have some time to discuss opportunities this week.

my linkedin profile: literally just desktop c++ work in a completely different domain.

yeah, something tells me these messages are not likely to lead to a real job.

Actually, I tried, and it does.

But have you ever tried? Back in 2018, less than 6 months into my new job I tried and got a solid offer (and found a client) that could be bumping my salary from €41,000 to €47,000. For reasons unknown I turned down the offer, and I retrospectively kind of regret it.

I'll respond if their initial message sounds like they actually read my profile and thought about how I could bring value to their client. this almost never happens. usually they are hiring for a mid-level role for which I have zero relevant experience. I have a hard time believing that's what they really want to do.

in any case, I really like my current team and manager. it would take a lot more than a €6000 (~$7000) salary bump to make me consider a different job.

> This is psycho advice. It ranks up there with the crazy myths about just being able to instantly get new software jobs (when the actual time of job searches is usually longer than 6 months, despite the tone deaf wave of gainsaying comments this is sure to incite).

Well, everyone I know who's any good as a developer can just waltz into a new job on Thursday after being fired on Tuesday.

/s, if it weren't obvious, but I've read enough straight-faced comments of this type on Hackernews.

You know you could search for a job while working at one you don’t like.

Not all advice is literal.

Also, not everyone’s goal is to foster organizational change some are trying to help themselves first.

The text ran the same section below that said "have something else lined up first" so the advice wasn't "quit at the drop of a hat".

And I do agree that it's rarely going to lead to any sort of corporate change. I worked at a place with around ... ~20 IT folks. New CEO came in, and within 9 months, 8 of the 20 had left or were leaving (I was one of them). I'd reached out to the previous CEO (who still owned the company, had interviewed me, and was one of the reasons I'd taken the job) and said "something's wrong here". "I don't want to hear it - talk to New CEO". "New CEO is the problem..." "Don't want to hear it...". So... loads of people left. It wasn't until New CEO tried to get rid of one person in particular did alarm bells finally go off, and owner/CEO came back and booted New CEO. So... change happened eventually, but not in reaction to 40% of the IT staff leaving in less than a year.

I tend to disagree with many of the sentiments. In particular, many software folks don’t know the most rudimentary data structures and algorithms. Those should be memorized, frankly. Lately I have been exploring old programming books on archive.org and realize how downhill the industry has gone from fundamental principles, which leads to “language-z” zealots to satisfy some business need.

The author mentions COBOL as being antiquated and irrelevant but in all honesty, modern languages don’t improve upon much. Underneath all the layers people add to modern languages (so the rest of the developer community can push buttons without even the faintest idea) lies assembly language and the machine.

Knowledge of the systems is abstracted away so much that people are focusing on mastering the wrong thing. One should be able to implement algorithms in C or COBOL or even assembly. Otherwise, it’s like learning to google the notes of a concerto without understanding the chords, scales, harmony, melody, etc.

I forget what I don't use. Should I rememorize those things every 6 months?

99% of the data structure decisions I make at work are whether I should use a vector, a tree, a hashmap, or (very rarely) a list. the standard library implementation of whatever I choose is almost always sufficient. I wouldn't expect the average programmer to be able to implement all of these on the spot, but if you don't use them enough to understand the basic trade-offs, I have to wonder wtf you are doing all day?

Every programming job is different. I worked for 6 years at a well known videogames company and never had to use a vector or a tree ever. I was mostly using lists and dictionaries and occasionally an array, and that’s about it. I never had to do anything more complex data structure wise than that and I never really had to write my own data structure nor anything approaching an algorithm.

that makes sense, but presumably you knew enough about vectors and trees to understand why you weren't using them?

I do APIs and Web Apps. I only learned the definitions for the data structures you mentioned for work interviews. Otherwise I wouldn't even know what they mean. But also above post mentioned memorising algorithms, so they seem to expect memorisation beyond knowing trade offs of the features your programming language provides.

They suggested one should have to know how to implement algorithms in Assembly to be useful.

Also the article author mentioned bubble sort as an example. Do you really need to know bubble sort by heart?

Even if you know the broad strokes, asking the average developer to implement most data structures will be a disaster. I'm reminded of the fact that most binary search algorithms are badly broken:

> When Jon Bentley assigned binary search as a problem in a course for professional programmers, he found that ninety percent failed to provide a correct solution after several hours of working on it, mainly because the incorrect implementations failed to run or returned a wrong answer in rare edge cases. A study published in 1988 shows that accurate code for it is only found in five out of twenty textbooks. Furthermore, Bentley's own implementation of binary search, published in his 1986 book Programming Pearls, contained an overflow error that remained undetected for over twenty years. The Java programming language library implementation of binary search had the same overflow bug for more than nine years.

Knuth had this to say:

> Although the basic idea of binary search is comparatively straightforward, the details can be surprisingly tricky

https://en.wikipedia.org/wiki/Binary_search_algorithm#Implem...

If the experts can't get it right, no developer in an interview setting has a chance. It's a game of "gotcha." The interviewer has some trick that they are privy to and are waiting for the interviewee to mess up and... GOTCHA! You got it wrong, it's this clever trick that you would have to know ahead of time! Silly person thinking they can get a job here without knowing the secret handshake.

I'm also one of those people who think people should know rudimentary data structures and algorithms, and the reason I think this is that they come up all the time!

Sure, you could get through the situations I'm thinking of without knowing anything about this, but if you don't think about it, you risk filling the code with lots of O(n^2) loops that could be O(n) if you added an extra map. This is how you end up with applications that are slow due to a thousand small cuts.

If you don't think about these things, then I can only assume that it's because you don't notice them when they come up.

To be clear, there's nothing wrong with choosing the slower implementation because its simpler. What's important is that you thought about the trade-off, and often the O(n) loop is not more complicated than the O(n^2) one.

It sounds like your position makes use of those data structures and algorithms - and the author's didn't. I think the key here is that you memorize the important aspects of your role while knowing how to get the answers for anything else.

Right. The author is otherwise memoizing ... via google.

I am having a lot of job interviews lately. Interviewers usually ask me about my latest experience. It was implementing a pretty clever parser involving a lot of memory management. So I give details about the algorithm to the interviewer. I try my best to make it simple to understand. But most of the time, I get this kind of comment: "That sounds great, but which kind of middleware/broker/framework did you use?" I answer: none, we crafted everything from scratch. And then come the "oh, no Angular then"? "Angular? What the fuck are you talking about?" And then I go into autistic mode: get lost, you buzzword seeker. So my piece of advice to everyone: algorithms don't get you hired.

I would reword "Vote with you feet" to be "It's OK to change jobs", so as to give it a broader meaning.

There is no obligation for you to stay in a job you don't like, or to pursue a different opportunity. You don't have to explain your reasons for leaving. Your employer and your team will probably be fine without you, and if they are not it is not your problem. To often I've stayed in a job I didn't like because "I'd be letting my team down" or "we're too busy, now is not a good time." Screw that. If you are not liking it, find something else and leave.

I'd also add one more: "Take your vacation". You are no good to anybody (you, your friends, your family, or your employer) if you work self to burn out. It's not worth it, and the world won't end while you are away.

> If you’re not familiar with the concept of T-shaped skills, or T-shaped people, don’t worry, most people are not. It’s an HR metaphor used to describe the skills of candidates. So if you think of your skills as plotted on a graph, you’ll notice you’ve got different levels in each. And if you unite those levels, you’d want them to create a T-shape instead of anything else.

I've always been a fan of 'pi' shaped skillset where you're deep in 2-ish+ areas rather than one core skill. It also means that you don't become known for just one singular thing. This becomes even better when the your deep areas complement each other and you'll find the sum greater than the parts.

Regarding "Learning to say no", I agree that's an under-emphasized skill.

Too often, the answer I give when asked "Could the software be made to do X?" is "Yes, it could, but no, it should not."

The exported data is in CSV. Excel can import it. Yes, I could import an Office library and write XLSX files natively, but while the person making the request screwed up by making the wrong selection after marking up the data with colors and saving it as a CSV, dropping those features, the right thing to do is not screw that up, not to add complexity to the software.

Even if you know how to say no, there are probably a few people up the chain who are paid to say yes.

Quite broad advice that just seems bad for new programmers.

Like, ask for help? You need to learn to solve stuff without disturbing the team.

Vote with your feet? Juniors are not in the position to do that.

People can't read your mind? Actually people are quite good at reading your mind and alot of things are supposed to be said by indirect hints to save face.

Soft skills? Way overrated - just don't be toxic and avoid obvoius trouble.

Know your worth? Build a brand? Say no?

This guy is just listing stuff he gets away with by not being new to the field. The advice would be worthless to himself when he bagan ...

Edit: The one advice I would like to have had is "no-one will notice if you give 110% or keep a 60% substainable pace. Relax and keep grinding".

> I come from a culture that values memorisation over creativity and problem-solving. Fuck that. To this day, I still Google how to bubble sort.

I really hope this is hyperbole, but you should never use bubble sort. I can't think of a single legitimate reason you'd want to use it. Insertion sort, is a good O(n^2) sort to know.

Insertion sort is probably the one you'd come up with anyway, if you didn't know any sorting algorithms. If asked to sort a deck of cards, guess which algorithm almost anyone would naively use.

If there are instead two people to sort the deck of cards, they'll probably invent some variant on a merge sort!

If you're working with rotating drum memory, bubble sort provides the best real world performance for any kind of data set that would fit on it.

Do I need to specify that I'm talking about modern computers? That's an interesting bit of trivia though.

I think it's a useful way to keep in mind that algorithmic complexity isn't everything in the real world, which also applies to today.

When would bubble sort be ideal? When it's relatively cheap to read data sequentially compared to backwards or randomly, and resetting to the initial read position isn't too costly.

Now I've nerd sniped myself, and am brainstorming how that situation might arise with modern systems...

It wasn't mentioned in the article but I'd say as developers, we often underestimate the amount of time a task/project would take.

Learning how to properly estimate a given task and delivering it on or before your proposed time-frame will make your life as a developer much better.

Tell us again in 20 more years. In this industry, YOU ARE JUST STARTING. I've been coding since '78 and reading this list is like a high school journal.

Googling how to bubble sort seems a bit extreme. I'm not much for Cracking the Code Interview type questions but this would certainly be a red flag.

A lot of people would google FizzBuzz unfortunately.

I'm about to do some interviewing and I am much more interested in how they would handle a credit card provider being down when processing a transaction. Or if they can articulate that solution verbally. Or if they handle me taking an opposite position as devil's advocate well, etc.

Absolutely. You want both but I would also value what you’re talking about a lot more.

Using a resilience library like Polly, if the transaction still fails after a few attempts then handle it according to business requirements.

https://github.com/App-vNext/Polly

I'd have to google "bubble sort" to even remember what it is; but I don't think that has any bearing on whether I'd understand it once I remembered what it was.

I'd tell you what it is in an interview if you asked. The author knows what it is but needs to google an implementation.

Part of the problem with things like "implement Bubble Sort" is that most actual programming tasks are "here's a problem, find the best implementation". There aren't many sorting tasks where Bubble Sort is an appropriate implementation: a _better_ interview question would be "here's a list of numbers, sort them without using a standard library function." Followed by "what are some advantages/disadvantages of the method you used? Can you think of a better way to do this?"

FizzBuzz also has zero practical value, yet it will filter out people who can't code.

But, the question is formulated like a normal programming task: it's not "implement this algorithm" it's "come up with a program that removes numbers that meet this specification".

That isn't a bad interview question but certainly not _better_. It's perfectly understandable for some shops to want to filter out people that don't practice fundamentals from time to time. We all have our own predictors of success and they all suck in different ways.

I have never needed to implement a sorting algorithm, so time spent memorizing them would be pretty wasteful compared to learning something useful.

I do remember Barack Obama advising against bubble sort though.

IIRC, bubble sort is only useful if you're sorting a doubly linked list in constant memory. Linked lists aren't that useful either. If you're iterating over the entire list and making changes in the middle, you're better off rebuilding the list as a vector because lower memory overhead makes two vectors smaller than one linked list. The most frequent correct uses of linked lists that I've seen are lock-free, concurrent data structures and hashtables that save insertion order.

I’ve been a programmer or otherwise involved with software since roughly 1998 and never had to write a bubble sort at work. Why would googling it be a red flag?

It might be surprising to the hackernews crew but 98% of software jobs have nothing in common with leetcode problems. Most people are writing Java, c#, JavaScript etc and using the built in data structures and doing list.Sort() or something similar.

I've never had to do a bubble sort outside of college/uni. You could ask me right now to do one and I wouldn't be able to do it without at least having the steps in written English.

I've never needed to use one, I can just do .OrderBy() or similar in the language I use.

Does that make me a bad developer?

You wouldn't get this question even in that style of interview. Besides bubblesort just being terrible for everything, you don't get many "implement X" questions even in coding style interviews, they just don't make for good questions.

Questions need to be in pursuit of some goal, with different options for implementation. Usually you'll get a question with a fairly simple naive implementation with terrible performance, then other options which have more favorable worst case running time.

Reply on news.ycombinator.com