6 ms·

Software development topics I've changed my mind on after 6 years in industry

37 points by saikatsg 2y ago

mbonnet 2y ago
This is a decent idea to do every few years. I may make my own version.
ramon156 2y ago
> After performing over 100 interviews, I can say that interviewing is thoroughly broken. I also have no idea how to actually make it better. I resonate with this greatly. I'm in the middle of applying for jobs, and I try to put myself into the recruiter's shoes. At the end of the day, I don't blame recruiters for the calls they make (e.g. ghosting, denying for $REASON). When you are supposed to interview a potential software dev, how are you going to differentiate the people you should invest into from the ChatGPT extension? How do you know whether the person actually worked at $FAANG_COMPANY for 3 years? Don't forget the other 78 people that also applied for the job.
- mdaniel 2y ago
  > I don't blame recruiters for the calls they make (e.g. ghosting, False. This is not Tinder: if you don't want to move forward, an email stating as much is super cheap.
  - EGreg 2y ago
    Tell me, why is it OK for Tinder?
    - stonogo 2y ago
      Because it's the basis of the product. You swipe and move on. Professional interactions are and ought to be different.
      - EGreg 2y ago
        Why ought they be different? ATS scans resumes and discards most of them. The whole thing has become just another dark forest
        stonogo 2y ago
        Parent comment was specifically commenting about recruiters, indicating there was human communication at some point, hence the term 'ghosting'. Anyway it's much the same, since most competent HR software can autosend a 'no thanks' email when the system bulk-rejects applications. Whether or not a person is involved, it's so little effort to send that close-of-conversation email that there's no reason not to. Meanwhile, the point of Tinder is that people choose when and how to engage. They're not the same.
        randomdata 2y ago
        And the comparison with Tinder also carried the implication that the successful swiping had already taken place that there was human-to-human communication that was happening, but where one party decided to no longer engage. There may be essentially no effort to say that you are no longer interested, but at the same time if you are no longer interested, who cares?
    - BobaFloutist 2y ago
      It's not necessarily, but interpersonal bad behavior reflects on your self, professional bad behavior reflects on your institution. The stakes are also higher. Yes, love is more important than money, but having a job at all is definitely lower on Maslow's hierarchy than finding a romantic partnership.
      - randomdata 2y ago
        > but interpersonal bad behavior reflects on your self, professional bad behavior reflects on your institution. Perhaps, but their self or their institution don't want you, so why would they be concerned with what you think of them? In the olden days where you only had the choice of the 20 people you could realistically get in touch with by horse, there was always an inkling in the back your mind that maybe you'll get desperate in the future, so there would be a lot of fear around completely destroying ties. But now that there are 8 billion people at your immediate disposal, there is no reason to cling to something you clearly don't want. In fact, if their actions give you a sour taste, that's ideal! It will save them from thinking you are a good idea later when they have a desperate moment. If their niceties leaves you still willing to engage even after they realized you're not a good option, that's not a good place for anyone.
- knallfrosch 2y ago
  > How do you know whether the person actually worked at $FAANG_COMPANY for 3 years? In the United States of America, you call the company. In Germany, employees get a certificate. If you get 100 applications for an opening, your HR tool can automatically send emails to declined candidates. You do track which ones you’ve rejected in the past and which ones you go forward with, right? And on and on. It’s not hard.
j-scott 2y ago
> People who stress over code style, linting rules, or other minutia are insane weirdos Stressing over these things is certainly a Sisyphean task. However, investing in automating and standardizing the application of these things every time a new repo is created eliminates an entire class of problems and saves you all sorts of trouble down the road.
- woooooo 2y ago
  Primarily it's protecting yourself from those weirdos by pre-empting them, though.
- jweir 2y ago
  Everyone uses the same formatter & options (which really should have no options, but that ins't the reality for most languages). The formatter rules - move on.
- meaydinli 2y ago
  I am one of those weirdos that like to work on "un-sexy" things behind the scenes which hopefully makes the life of my colleagues a bit better with every attempt. I don't think it is necessary for small teams, and may even be considered a waste of time, but once a team is sufficiently big and spread out, I think a few people working in the background, keeping watch of things, cleaning up after people, proactively improving stuff, creating and enforcing rules and standards is very beneficial and necessary for a team's next growth spurt.
allochthon 2y ago
Overall I like the list. Some of the bullet points were stated a little more strongly than I was comfortable with. > People who stress over code style, linting rules, or other minutia are insane weirdos I feel like programmatically enforced linting is like keeping a shared house clean. Suppose you live in a house with roommates. You wipe off the counters, you clean up after yourself, you put dishes in the dishwasher, so that the house is tidy and pleasant. If there's a lint or style rule that requires judgment and is hard to enforce programmatically, perhaps better left as an occasional PR comment. Programatically enforced linting also has the benefit of removing degrees of freedom that aren't very important and don't merit getting bogged down about.
- randomdata 2y ago
  To be fair, those who become uncomfortable from words are equally insane weirdos.
- arp242 2y ago
  The problem is that many linters are excessively pedantic, require workarounds that are just silly, and if we ask "does it actually improve things?" then ... often not really, not in a substantial way. Once you agree on the "big basics" like brace style or whatever makes sense for your language, you quickly get diminishing (often miniscule) returns. This also ties in to what I call the "linter fallacy"; which goes something like: "This code passes 56 linters" "Therefore, it's good code" And the related: "Our code is a mess" "I spent a week adding 56 linters and rewriting it all to pass" "Therefore, now our code is good" What really matters is "can I read this code naturally?" And if the answer to that is "yes" then it may be good code. Obsessing over whether it should be written with some small differences that don't really matter is just not useful for anyone.
theideaofcoffee 2y ago
> Standups are actually useful for keeping an eye on the newbies. If you're relying on a daily standup to keep the newbies on track, then something is deeply broken with your management and people development structure. They should be continually coached one-on-one, rather than left to fend for themselves only then to pipe up once per day. A little time investment by both the noob and someone more seasoned really, genuinely helps them to get up to speed. It's something that will pay itself back many times over in the future. I've experienced both when I stepped in as a greenhorn, I leveled up so much faster when I had the ability to pepper questions throughout the day to someone more seasoned. And I remember feeling discouraged and listless in a culture where you don't interrupt the senior people, wait for the standup, regurgitate your problems, speak the scrum prayer every morning. Does it cost something in terms of efficiency, or vElOCiTy? Sure, but like I said above, the returns on investment compound when you really care about developing people, and not being a slave to the scrum process.
- polishdude20 2y ago
  I completely agree. Even seniors who have just joined your org need a buddy to help get up to speed and pick their brain. Standup isn't the place to learn how to do your job.
hyggetrold 2y ago
Nice article. These stood out to me: > Software architecture matters probably more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot. > Pencil and paper are the best programming tools and vastly under used. > Code coverage has absolutely nothing to do with code quality. > Micro-services require justification.
kccqzy 2y ago
> Code coverage has absolutely nothing to do with code quality I'm going to disagree respectfully here. I don't think hard-and-fast rules on code coverage are useful (e.g. must achieve 90% coverage before merging), but just having code coverage run automatically and its results displayed is useful. When I add an "if" check and one of the branches isn't covered for example, I start to think what if some junior engineer didn't understand the reason behind this "if" check and decided to delete this check altogether? If no unit tests fail after deleting this check, that junior engineer might not have enough context to judge whether this check is needed in production.
- mdaniel 2y ago
  You actually brought to my attention a metric that I hadn't previously considered but now desperately want: branch coverage. I don't need 90% of lines covered, because one cannot measure coverage of missing lines /* BadImpl.java */ if (theFile.exists()) { doTheAwesome(theFile); } // uh, and else ... what? /* BadImplTest.java */ @Test public void looksGoodTestCoverage() { theFile.create(); instance.runIt(); println("hurray, 100% coverage"); } versus if the coverage tool was able to artificially rewrite the code to be this way, it would show up as not covered: if (theFile.exists()) { ... } else { }
- randomdata 2y ago
  You're really speaking about documentation quality, though. The most horribly written code ever written can still do a good job of documenting what the "if" does. I think the real takeaway here is that code quality doesn't really matter. The most horribly written code is still quite fine to work with if well documented.
randomdata 2y ago
> Code coverage has absolutely nothing to do with code quality It is quite indicative of documentation quality, though, which is most important as a codebase ages. You may know how it works now without documentation, but future developers (which may include you) are going to want more information to know what kind of expectations are found around the code.
JohnMakin 2y ago
> 90%, maybe 93%, of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. This is more a statement on how many bad project managers there are rather than on the role itself being useless. I've worked as an IC with a lot of PM's over the course of my career - I can definitely bring to mind a few PM's that left a huge impression on the project I was working on. I can think of many more that were completely worthless. I think the latter group makes developers think the role itself is useless, which I could not disagree more with. Developers are absolutely terrible at balancing business and customer priorities with technical ones, and the worst part is, many of them believe they aren't bad at that.
- jatins 2y ago
  Agreed, I used to believe the same until I worked with a good project manager. But in hindsight they went way beyond their responsibilities and actually served as a mix of product/project/engineering manager. So maybe author's point stands in the sense most "project managers" think their job is moving jira tickets from one state to other
- randomdata 2y ago
  > Developers are absolutely terrible at balancing business and customer priorities with technical ones True, but project managers are even worse! (There are always exceptions)
- BobaFloutist 2y ago
  If the plurality are bad at their job, maybe the role itself needs at the very least a hard look. Any time you find yourself saying "It's not the field that's fundamentally broken, it's that (almost) every individual in it just happens to suck (at it)," you need to take a step back and realize that that's the same problem. If you have to be exceptionally skilled at something to do it in a way that's net positive, and that field doesn't reasonable filter for the exceptionally competent, then the field is setting individuals up for failure, and needs to be restructured. And if most people in the role suck at it, you by definition have to be exceptionally skilled to succeed. Even if from the outside it looks like the people just tend to suck and the field is easy.
mdaniel 2y ago
(2021) Previously: 2022 https://news.ycombinator.com/item?id=32162716 https://news.ycombinator.com/item?id=32162716 2021 https://news.ycombinator.com/item?id=25887373 https://news.ycombinator.com/item?id=25887373
mdaniel 2y ago
> Standups are actually useful for keeping an eye on the newbies. ... and thus should include only project managers and/or team leaders and leave the rest of the professionals to do work and provide status updates via the bug tracker
- cynicalsecurity 2y ago
  It's really bad when standups last for half an hour. A standup must include 5-7 people at most and last no longer than 15 mins. Preferably 5-10. Anything else should be discussed outside of standup between specific team members only.
  - mdaniel 2y ago
    See, I have almost the opposite opinion: it costs more interruption and "life stupidity" to have 7 people stand up, assemble, stop talking about sports, go around the room saying "no blockers," go get a pastry, go back to their desks, unlock their workstations, try to remember what the hell they were trying to do before all that dumbness. All of that to just hear the exact same thing any sane person who gave a shit could have read on a report emailed to them that morning, or -- more common in my experience -- that they would have read in the Mattermost/Slack/Teams/Zulip from the past day If one wants a status report, fine, have one periodically. But don't vaporize 30 minutes a day times 7 people just to go around the room talking. What a 1950s concept holy shit I have never in my life met a professional who sits on their hands for 23 hours waiting to say "uh, I have a blocker, but wanted to save it for this magic 15 minutes to ask for help." Yes, fine, n00bs do that, and that's what TFA was saying that interns need supervision, who knew.
    - theideaofcoffee 2y ago
      Hard agree. It's all just devolved into cargo cult nonsense, follow the process, to parrot what they think large orgs are doing. And if you have an adequately competent culture, those noobs aren't going to be left hanging, they're going to learn that it's ok to ask to help get unblocked, and that's what should be taught. And yeah, I also can't agree more with your assessment about status reports being this relic from the past. What is this? The military? "SITREP. NOW!" Such a waste of breath, time, human life.

37 points by saikatsg 2y ago

This is a decent idea to do every few years. I may make my own version.

> After performing over 100 interviews, I can say that interviewing is thoroughly broken. I also have no idea how to actually make it better. I resonate with this greatly. I'm in the middle of applying for jobs, and I try to put myself into the recruiter's shoes. At the end of the day, I don't blame recruiters for the calls they make (e.g. ghosting, denying for $REASON). When you are supposed to interview a potential software dev, how are you going to differentiate the people you should invest into from the ChatGPT extension? How do you know whether the person actually worked at $FAANG_COMPANY for 3 years? Don't forget the other 78 people that also applied for the job.

mdaniel 2y ago
> I don't blame recruiters for the calls they make (e.g. ghosting, False. This is not Tinder: if you don't want to move forward, an email stating as much is super cheap.
- EGreg 2y ago
  Tell me, why is it OK for Tinder?
  - stonogo 2y ago
    Because it's the basis of the product. You swipe and move on. Professional interactions are and ought to be different.
    - EGreg 2y ago
      Why ought they be different? ATS scans resumes and discards most of them. The whole thing has become just another dark forest
      - stonogo 2y ago
        Parent comment was specifically commenting about recruiters, indicating there was human communication at some point, hence the term 'ghosting'. Anyway it's much the same, since most competent HR software can autosend a 'no thanks' email when the system bulk-rejects applications. Whether or not a person is involved, it's so little effort to send that close-of-conversation email that there's no reason not to. Meanwhile, the point of Tinder is that people choose when and how to engage. They're not the same.
        randomdata 2y ago
        And the comparison with Tinder also carried the implication that the successful swiping had already taken place that there was human-to-human communication that was happening, but where one party decided to no longer engage. There may be essentially no effort to say that you are no longer interested, but at the same time if you are no longer interested, who cares?
  - BobaFloutist 2y ago
    It's not necessarily, but interpersonal bad behavior reflects on your self, professional bad behavior reflects on your institution. The stakes are also higher. Yes, love is more important than money, but having a job at all is definitely lower on Maslow's hierarchy than finding a romantic partnership.
    - randomdata 2y ago
      > but interpersonal bad behavior reflects on your self, professional bad behavior reflects on your institution. Perhaps, but their self or their institution don't want you, so why would they be concerned with what you think of them? In the olden days where you only had the choice of the 20 people you could realistically get in touch with by horse, there was always an inkling in the back your mind that maybe you'll get desperate in the future, so there would be a lot of fear around completely destroying ties. But now that there are 8 billion people at your immediate disposal, there is no reason to cling to something you clearly don't want. In fact, if their actions give you a sour taste, that's ideal! It will save them from thinking you are a good idea later when they have a desperate moment. If their niceties leaves you still willing to engage even after they realized you're not a good option, that's not a good place for anyone.
knallfrosch 2y ago
> How do you know whether the person actually worked at $FAANG_COMPANY for 3 years? In the United States of America, you call the company. In Germany, employees get a certificate. If you get 100 applications for an opening, your HR tool can automatically send emails to declined candidates. You do track which ones you’ve rejected in the past and which ones you go forward with, right? And on and on. It’s not hard.

j-scott 2y ago

> People who stress over code style, linting rules, or other minutia are insane weirdos Stressing over these things is certainly a Sisyphean task. However, investing in automating and standardizing the application of these things every time a new repo is created eliminates an entire class of problems and saves you all sorts of trouble down the road.

woooooo 2y ago
Primarily it's protecting yourself from those weirdos by pre-empting them, though.
jweir 2y ago
Everyone uses the same formatter & options (which really should have no options, but that ins't the reality for most languages). The formatter rules - move on.
meaydinli 2y ago
I am one of those weirdos that like to work on "un-sexy" things behind the scenes which hopefully makes the life of my colleagues a bit better with every attempt. I don't think it is necessary for small teams, and may even be considered a waste of time, but once a team is sufficiently big and spread out, I think a few people working in the background, keeping watch of things, cleaning up after people, proactively improving stuff, creating and enforcing rules and standards is very beneficial and necessary for a team's next growth spurt.

allochthon 2y ago

Overall I like the list. Some of the bullet points were stated a little more strongly than I was comfortable with. > People who stress over code style, linting rules, or other minutia are insane weirdos I feel like programmatically enforced linting is like keeping a shared house clean. Suppose you live in a house with roommates. You wipe off the counters, you clean up after yourself, you put dishes in the dishwasher, so that the house is tidy and pleasant. If there's a lint or style rule that requires judgment and is hard to enforce programmatically, perhaps better left as an occasional PR comment. Programatically enforced linting also has the benefit of removing degrees of freedom that aren't very important and don't merit getting bogged down about.

randomdata 2y ago
To be fair, those who become uncomfortable from words are equally insane weirdos.
arp242 2y ago
The problem is that many linters are excessively pedantic, require workarounds that are just silly, and if we ask "does it actually improve things?" then ... often not really, not in a substantial way. Once you agree on the "big basics" like brace style or whatever makes sense for your language, you quickly get diminishing (often miniscule) returns. This also ties in to what I call the "linter fallacy"; which goes something like: "This code passes 56 linters" "Therefore, it's good code" And the related: "Our code is a mess" "I spent a week adding 56 linters and rewriting it all to pass" "Therefore, now our code is good" What really matters is "can I read this code naturally?" And if the answer to that is "yes" then it may be good code. Obsessing over whether it should be written with some small differences that don't really matter is just not useful for anyone.

theideaofcoffee 2y ago

> Standups are actually useful for keeping an eye on the newbies. If you're relying on a daily standup to keep the newbies on track, then something is deeply broken with your management and people development structure. They should be continually coached one-on-one, rather than left to fend for themselves only then to pipe up once per day. A little time investment by both the noob and someone more seasoned really, genuinely helps them to get up to speed. It's something that will pay itself back many times over in the future. I've experienced both when I stepped in as a greenhorn, I leveled up so much faster when I had the ability to pepper questions throughout the day to someone more seasoned. And I remember feeling discouraged and listless in a culture where you don't interrupt the senior people, wait for the standup, regurgitate your problems, speak the scrum prayer every morning. Does it cost something in terms of efficiency, or vElOCiTy? Sure, but like I said above, the returns on investment compound when you really care about developing people, and not being a slave to the scrum process.

polishdude20 2y ago
I completely agree. Even seniors who have just joined your org need a buddy to help get up to speed and pick their brain. Standup isn't the place to learn how to do your job.

hyggetrold 2y ago

Nice article. These stood out to me: > Software architecture matters probably more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot. > Pencil and paper are the best programming tools and vastly under used. > Code coverage has absolutely nothing to do with code quality. > Micro-services require justification.

kccqzy 2y ago

> Code coverage has absolutely nothing to do with code quality I'm going to disagree respectfully here. I don't think hard-and-fast rules on code coverage are useful (e.g. must achieve 90% coverage before merging), but just having code coverage run automatically and its results displayed is useful. When I add an "if" check and one of the branches isn't covered for example, I start to think what if some junior engineer didn't understand the reason behind this "if" check and decided to delete this check altogether? If no unit tests fail after deleting this check, that junior engineer might not have enough context to judge whether this check is needed in production.

mdaniel 2y ago
You actually brought to my attention a metric that I hadn't previously considered but now desperately want: branch coverage. I don't need 90% of lines covered, because one cannot measure coverage of missing lines /* BadImpl.java */ if (theFile.exists()) { doTheAwesome(theFile); } // uh, and else ... what? /* BadImplTest.java */ @Test public void looksGoodTestCoverage() { theFile.create(); instance.runIt(); println("hurray, 100% coverage"); } versus if the coverage tool was able to artificially rewrite the code to be this way, it would show up as not covered: if (theFile.exists()) { ... } else { }
randomdata 2y ago
You're really speaking about documentation quality, though. The most horribly written code ever written can still do a good job of documenting what the "if" does. I think the real takeaway here is that code quality doesn't really matter. The most horribly written code is still quite fine to work with if well documented.

randomdata 2y ago

> Code coverage has absolutely nothing to do with code quality It is quite indicative of documentation quality, though, which is most important as a codebase ages. You may know how it works now without documentation, but future developers (which may include you) are going to want more information to know what kind of expectations are found around the code.

JohnMakin 2y ago

> 90%, maybe 93%, of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. This is more a statement on how many bad project managers there are rather than on the role itself being useless. I've worked as an IC with a lot of PM's over the course of my career - I can definitely bring to mind a few PM's that left a huge impression on the project I was working on. I can think of many more that were completely worthless. I think the latter group makes developers think the role itself is useless, which I could not disagree more with. Developers are absolutely terrible at balancing business and customer priorities with technical ones, and the worst part is, many of them believe they aren't bad at that.

jatins 2y ago
Agreed, I used to believe the same until I worked with a good project manager. But in hindsight they went way beyond their responsibilities and actually served as a mix of product/project/engineering manager. So maybe author's point stands in the sense most "project managers" think their job is moving jira tickets from one state to other
randomdata 2y ago
> Developers are absolutely terrible at balancing business and customer priorities with technical ones True, but project managers are even worse! (There are always exceptions)
BobaFloutist 2y ago
If the plurality are bad at their job, maybe the role itself needs at the very least a hard look. Any time you find yourself saying "It's not the field that's fundamentally broken, it's that (almost) every individual in it just happens to suck (at it)," you need to take a step back and realize that that's the same problem. If you have to be exceptionally skilled at something to do it in a way that's net positive, and that field doesn't reasonable filter for the exceptionally competent, then the field is setting individuals up for failure, and needs to be restructured. And if most people in the role suck at it, you by definition have to be exceptionally skilled to succeed. Even if from the outside it looks like the people just tend to suck and the field is easy.

mdaniel 2y ago

(2021) Previously: 2022 https://news.ycombinator.com/item?id=32162716 https://news.ycombinator.com/item?id=32162716 2021 https://news.ycombinator.com/item?id=25887373 https://news.ycombinator.com/item?id=25887373

mdaniel 2y ago

> Standups are actually useful for keeping an eye on the newbies. ... and thus should include only project managers and/or team leaders and leave the rest of the professionals to do work and provide status updates via the bug tracker

cynicalsecurity 2y ago
It's really bad when standups last for half an hour. A standup must include 5-7 people at most and last no longer than 15 mins. Preferably 5-10. Anything else should be discussed outside of standup between specific team members only.
- mdaniel 2y ago
  See, I have almost the opposite opinion: it costs more interruption and "life stupidity" to have 7 people stand up, assemble, stop talking about sports, go around the room saying "no blockers," go get a pastry, go back to their desks, unlock their workstations, try to remember what the hell they were trying to do before all that dumbness. All of that to just hear the exact same thing any sane person who gave a shit could have read on a report emailed to them that morning, or -- more common in my experience -- that they would have read in the Mattermost/Slack/Teams/Zulip from the past day If one wants a status report, fine, have one periodically. But don't vaporize 30 minutes a day times 7 people just to go around the room talking. What a 1950s concept holy shit I have never in my life met a professional who sits on their hands for 23 hours waiting to say "uh, I have a blocker, but wanted to save it for this magic 15 minutes to ask for help." Yes, fine, n00bs do that, and that's what TFA was saying that interns need supervision, who knew.
  - theideaofcoffee 2y ago
    Hard agree. It's all just devolved into cargo cult nonsense, follow the process, to parrot what they think large orgs are doing. And if you have an adequately competent culture, those noobs aren't going to be left hanging, they're going to learn that it's ok to ask to help get unblocked, and that's what should be taught. And yeah, I also can't agree more with your assessment about status reports being this relic from the past. What is this? The military? "SITREP. NOW!" Such a waste of breath, time, human life.