9 ms·

Things nobody told me about being a software engineer

102 points by chad_strategic 8y ago

chad_strategic 8y ago
I'm working in Drupal 8, which makes rule 17 = true.
Insanity 8y ago
Don't agree with all the rules, some depend on where you work (e.g, we don't have a lot of tests in our ~30 year old codebase) . However, Rule #2 is true for me. Accidentally pressing those keybindings in a textfield that does not accept them has become common.
- aequitas 8y ago
  Try pressing them in other situations and you might be surprised how often they work, Youtube player for example to pause, forward/rewind.
Mc_Big_G 8y ago
How about: When searching for a new job, your previous years of experience, github repos, personal projects, consulting gigs and all other relevant information about your ability to produce quality software will not matter at all compared to your ability to do leetcode style programming challenges.
- t0mbstone 8y ago
  That depends on the company you are wanting to work at, though. I refuse to work at companies that give those kinds of bullshit puzzle interviews.
  - maerF0x0 8y ago
    That's almost the entirety of the bay area.
    - aequitas 8y ago
      For me, moving to the bay area would be a bigger problem than these kinds of interviews anyway. All interviews I have done the lasts years didn't involve code challenges.
  - dominotw 8y ago
    > I refuse to work at companies that give those kinds of bullshit puzzle interviews. Good luck finding a job then. All companies of all sizes and locations do this.
    - AnimalMuppet 8y ago
      Um, no, they don't. I know of at least one exception - the one I work at. And I'm part of the interviews for our team, so I know how they're done.
      - dominotw 8y ago
        Ah ok. I 've been interviewing bunch of places recently. All of them seem to have identical format. I remember there a site I saw here HN that listed companies without whiteboard interviews. Can't think of the name.
        AnimalMuppet 8y ago
        Oh, no, we do whiteboard interviews. But they aren't those kind of stupid puzzles. We just have candidates write a little code, and do a little design. The "write a little code" is not one of those leetcode questions - it's really a simple problem. We just want to watch them code, and to hear what they're thinking as they do it.
        ryall 8y ago
        This is the way to do it. How an applicant applies process to problem solving and communicates their ideas, is way more important than being able to regurgitate bubble-sort.
    - dragonwriter 8y ago
      I don't apply to many jobs (I've got a tolerable one and am picky about location and other things), but the one startup tech job I applied to didn't do puzzles, they did do a screenshared coding portion, but it wasn't a puzzle kind of thing.
  - jackconnor 8y ago
    Isn't this all of them?
- president 8y ago
  "America lacks top notch engineers" - Says every large tech company. It didn't dawn on me until now that, "top notch engineers" really just means "people that are good at passing algorithm interviews". So many people I work with can code every algorithm on leetcode in a jiffy but can't write quality software that works.
  - mixmastamyk 8y ago
    The "tech shortage" in a nutshell.
- philwelch 8y ago
  > previous years of experience, github repos, personal projects, consulting gigs and all other relevant information about your ability As far as evidence for a hiring decision goes, all of the things you listed are things that can either be easily faked, are hard to verify, or require implicitly trusting another organization. How am I supposed to spend the time reading all the code on your github account and forming a judgment of your ability based on that? Even if I do that, how can I be sure that you're the one who wrote that code? How do I know that your previous employers and clients weren't all bozos or that you didn't slack off and let your teammates do all the work? Even if I call your references, they'll probably just say, "yes, this guy definitely worked here, and by HR policy I'm not allowed to say more". Even if they do say more, how am I supposed to trust them? There's not nearly enough information there to make a hiring decision.
  - joshwcomeau 8y ago
    > How am I supposed to spend the time reading all the code on your github account Easy - spend the 45 minutes that you had allotted for whiteboard challenges. > how can I be sure that you're the one who wrote that code? You can't be, if the Github account has a single repo with a single commit. But impressive OSS has a history of commits, maybe even a community working with the applicant. As a random example, do you really think it would be possible for someone to fake an account like this? https://github.com/pedronauck https://github.com/pedronauck Even if someone went through the trouble to clone someone else's repo, modify all the commit messages to re-attribute them, and modify the code and commit messages enough to make it not obvious plagiarism, do you really think they could bullshit their way through a quick conversation about the code? Spend 20 minutes digging into it, and then ask pertinent questions about decisions made in the architecture. It'll become clear if this person is the author. It's theoretically possible that someone could put in all the work to pull off a convincing fraud, but do you really think that's likely? > How do I know that your previous employers and clients weren't all bozos or that you didn't slack off and let your teammates do all the work? It's true that there is no perfect signal here, but the odds of this being true are not 50/50. It's not 100% accurate, but having references and employment history is better than nothing. --- To be clear, I don't think OSS inspection is perfect as a hiring tool - it biases towards folks with the privilege to spend their free time working on passion projects - and I'd object to it being the sole determining factor. But I think the signal is far stronger than it is from whiteboarding, where the false negative rate is super high (I doubt most competent programmers would accurately showcase their skill in this environment). There is no perfect hiring practice, but to immediately disregard anything that has even a negligible potential for fraud feels a bit silly to me.
t0mbstone 8y ago
Pretty much all of these ring true for me (20+ years in the industry).
13of40 8y ago
Hand-wringing and debating about how we should use the bug reporting system, triage, sprint planning, user stories, burn-down charts, etc. will keep the leads and PMs busy for decades on end, even if the tools never change.
maerF0x0 8y ago
> That my gender or my age or my ethnicity or my sexual orientation or my weight or my clothes might (will!) have an impact on the perceived quality of the software I build. (Or, in other words, that this is not really a meritocracy, and doing a good job is not nearly enough.) Does there exist any body of proof around this one? Would like to see it and add it to my corpus of knowledge
- luckydata 8y ago
  go out in the world and pay attention for a few days, you'll get all the proof you need.
- deleted 8y ago
  [deleted]
- lozaning 8y ago
  Well I certainly hope I havent been growing out this Unix beard for nothing!
  - mixmastamyk 8y ago
    Grey beards no longer allowed at some places, so grab a Just for Men.
- Beldin 8y ago
  Yes. One typical test is to have people evaluate identical resumes, with the thing being checked for constituting the only difference (e.g. "ethnic" ames vs. "regular" names). Other data points are gathered by studying success at finding internships. A recent study found a rather staggering difference - names indicating local ethnicity got a place in 1-2 letters, while some other ethnicities had to write over 20 (if memory serves). You'll want to find studies for the country you're living in, as the parameters inevitably vary (e.g. which ethnicities to compare). I don't think the outcomes cary much, but i didn't do a comparative study on the literature.
  - bytematic 8y ago
tinnet 8y ago
Re #18: It exists, it's called mutation testing, and it's awesome (I only know the Java variant called http://pitest.org http://pitest.org)
- epmatsw 8y ago
  Stryker is a JS version. Google has some interesting whitepapers about their usage of mutation testing as well: https://ai.google/research/pubs/pub46584 https://ai.google/research/pubs/pub46584
- r-s 8y ago
  Ruby, too: https://github.com/mbj/mutant https://github.com/mbj/mutant I think most languages have something like this now.
redleggedfrog 8y ago
"That my gender or my age or my ethnicity or my sexual orientation or my weight or my clothes might (will!) have an impact on the perceived quality of the software I build." After nearly three decades writing software, I'd say if that's the case, you're probably at the wrong place. With such circumstances I'd suspect a whole lot of other bad things are probably true, too.
- dj-wonk 8y ago
  I interpret this comment as saying: if you find yourself in that kind of situation, look around and try to find other opportunities. In other words, life is too short. I also can see the other side: life is often not fair, particularly in the short-run. Life constraints such as geography are real barriers for many people.
  - redleggedfrog 8y ago
    You are not only an excellent interpreter, but an astute reflector.
amelius 8y ago
> That the new Altavista competitor would become a less bad Microsoft Office. That the new version of My Space would help damage democracies the world over. And that programmers would get a reputation almost as bad as bankers ...
- watwut 8y ago
  I think it is more enterpreneurs and startup founders who get all the hate, not so much run of mill programmers.
kenhwang 8y ago
> 8. That having decent people skills makes my technical skills suspect, in the eyes of some. I'm questioning how true this is, especially in today's world of whiteboard interviews and open office spaces. My personal experience seems to suggest that better people skills suggest better technical skill, especially to management.
- AnimalMuppet 8y ago
  Given the author's name, I think she's female. I fear that, for a female, #8 is more likely to be true than for a male.
- danielh96 8y ago
  I feel like they might be referring to peers here rather than management
- avgDev 8y ago
  Not long ago, I failed two sql whiteboard problems and passed 2 c# problems. I was informed by HR that they are making me an offer based on my great people skills, even though I failed their SQL quesitons. I sucked at white boarding(still do because I don't like grinding leetcode before interviews, and I usually make it known). When I first started interviewing I needed like 10 minutes to come up with palindrome solution even though I did it in school so many times. That time I also received an offer. Now, that I think of it I my success rate is 75% and that includes a fortune 1k company. However, it is a pretty small sample size. Now, that I think of it I need to interview more.
- watwut 8y ago
  I have seen that. I also seen people openly talking about social skills being opposite of coding skills and literally making implications about others. I have seen people pretend lower social skill then they actually have. The most common through is assuming that someone with bad social skills is genius in coding with zero grounds for it. Without seeing code or even talking with those who know his code closely, anything like that. Assumption was that that those people are better in coding because got knows why. I suspect part of it is wish to compensate, but part is stereotype. Open offices have nothing with it, except making people with poor social skills more actively annoying. Which can cancel some of effect I guess.
arkh 8y ago
> why is this not a standard feature of testing frameworks? I want some way to re-run tests flipping some of the assertions, to make sure they are testing what I think they are. That's mutation testing and it the next big thing for tests.
wyldfire 8y ago
> That you can have more than a 100% base salary difference doing the same job, depending on if you work at a small startup or one of the large companies. Even among and within large companies. Somewhat less so within, usually. But one element of that is the (US?) taboo around sharing compensation info.
rco8786 8y ago
> PHP is cool again Come again?
mattmanser 8y ago
Serious question, I've been programming 15 odd years, somewhere around a million people used my code last year, I've written entire sites on my own that happily run today. I don't write tests. Projects that already had tests, those tests caught a single bug in about 3.5 years of working on that code base. Yes, 1 bug. We'd have picked it up anyway when actually testing it. Why do you feel #1 or #16 are actually true? Am I (and colleagues) a magic snowflake, or are tests a massive waste of time, or is it somewhere in the middle?
- youeseh 8y ago
  It comes down to the cost of failure. If the cost of failure for a particular module say, payments processing or rocket guidance system, is high then writing tests could be much cheaper than waiting for a failure, especially in production.
- pathseeker 8y ago
  >I've written entire sites on my own that happily run today. This is probably the key issue. You're either working by yourself or you are on small enough team projects that it's easy to recognize when you are breaking things with a change. Tests are about rapidly detecting regressions in a programmatic way. It should not require manually testing every time you want to make a small change to the code base and if you depend on reviewers seeing that a change will break something, you are in for a world of hurt on any large project. Every large project I've been on that has skipped tests has ended up turning into a shitshow where master is broken for days at a time and you can't even tell the cause without hours of manual testing with bisection.
  - beokop 8y ago
    > if you depend on reviewers seeing that a change will break something, you are in for a world of hurt on any large project. I don’t agree with this at all. Here’s a counter example: Linux. I think the real problem here is that people don’t take review seriously and/or just don’t care about the project. We build these complicated, expensive systems that do all the thinking for us, not because it’s better, but because we simply don’t care. Having tests is better than letting sloppy developers run amok. In my experience though tests aren’t really needed on projects with a maintainer that actually gives a damn.
jackconnor 8y ago
Frontend programmers are very, very undervalued, I 100% agree. This is because they build the things that your user interacts directly with, where the "rubber meets the road", so to speak. Good FE coders are worth their weight in gold, to any company that has users using their software.
mh8h 8y ago
> 20. That it is all people, all the way down. They are as cute as turtles, but don’t have hard shells. A thousand times this. I used to be amazed by people's intelligence. Now I am amazed by their kindness.
- iam_takada 8y ago
  This analogy is lost on me. Could you explain?
  - BerislavLopac 8y ago
    https://en.wikipedia.org/wiki/Turtles_all_the_way_down https://en.wikipedia.org/wiki/Turtles_all_the_way_down
nraynaud 8y ago
funny how people confuse being told something and integrating it. We're "told" millions of things (more exactly we read all day long), some of it sticks some of it doesn't, it has nothing to do with what we believe is important later in life. I think we have to stop with those things I wish i was told/nobody told me/I would told my younger self. We just decide some points are salient with experience, and I'm pretty sure the list is different after every decade in life.
obelos 8y ago
Regarding #2, I have a harder time switching between touch screen vs. touch pad than I do between text editor key bindings. I seamlessly shift between vi and emacs throughout the day depending on what I'm editing, but put my laptop and tablet side by side and I am forever trying to touch the laptop screen.
watwut 8y ago
That people who write all those cool blogs/talks and people who write good code or manage projects in great way are different in important ways. Meaning what is good tech/code and what is hip on blogs and forums are two distinct groups. Meaning what is good management is completely different then both feel good and look at me I tough bs you find on blogs.
Erem 8y ago
The author was maybe the best engineer I've had the pleasure to work with directly in my 13 years in the industry. What a treat to read her internal thoughts on the job. Highly recommend her other posts on e.g. measuring performance of engineers https://anaulin.org/blog/why-do-we-have-performance-evaluations-anyway/ https://anaulin.org/blog/why-do-we-have-performance-evaluati...
poulsbohemian 8y ago
On this point about testing... what’s still surprising to me after twenty years of doing this is how many errors aren’t technical errors, but rather because someone forgot / failed to document / communicate how something was supposed to work. So something fails, fingers get pointed in the direction of the technical team, but the root cause is all too human.
purplezooey 8y ago
How about: one's abilities count for about 10%, and skill level in high school politics the other 90%.
amriksohata 8y ago
The thing no one told me is the number of requirements folk, like ux, ba's that don't understand their role in agile development and responsibilities in getting solid requirements across to developers
websitescenes 8y ago
Lost me at #13. CSS is not a programming language, nor is it complex..
klohto 8y ago
Article full of hyperboles, without-proof points and self-pity. Doesn't bring anything useful.

I'm working in Drupal 8, which makes rule 17 = true.

Don't agree with all the rules, some depend on where you work (e.g, we don't have a lot of tests in our ~30 year old codebase) . However, Rule #2 is true for me. Accidentally pressing those keybindings in a textfield that does not accept them has become common.

aequitas 8y ago
Try pressing them in other situations and you might be surprised how often they work, Youtube player for example to pause, forward/rewind.

Mc_Big_G 8y ago

How about: When searching for a new job, your previous years of experience, github repos, personal projects, consulting gigs and all other relevant information about your ability to produce quality software will not matter at all compared to your ability to do leetcode style programming challenges.

t0mbstone 8y ago
That depends on the company you are wanting to work at, though. I refuse to work at companies that give those kinds of bullshit puzzle interviews.
- maerF0x0 8y ago
  That's almost the entirety of the bay area.
  - aequitas 8y ago
    For me, moving to the bay area would be a bigger problem than these kinds of interviews anyway. All interviews I have done the lasts years didn't involve code challenges.
- dominotw 8y ago
  > I refuse to work at companies that give those kinds of bullshit puzzle interviews. Good luck finding a job then. All companies of all sizes and locations do this.
  - AnimalMuppet 8y ago
    Um, no, they don't. I know of at least one exception - the one I work at. And I'm part of the interviews for our team, so I know how they're done.
    - dominotw 8y ago
      Ah ok. I 've been interviewing bunch of places recently. All of them seem to have identical format. I remember there a site I saw here HN that listed companies without whiteboard interviews. Can't think of the name.
      - AnimalMuppet 8y ago
        Oh, no, we do whiteboard interviews. But they aren't those kind of stupid puzzles. We just have candidates write a little code, and do a little design. The "write a little code" is not one of those leetcode questions - it's really a simple problem. We just want to watch them code, and to hear what they're thinking as they do it.
        ryall 8y ago
        This is the way to do it. How an applicant applies process to problem solving and communicates their ideas, is way more important than being able to regurgitate bubble-sort.
  - dragonwriter 8y ago
    I don't apply to many jobs (I've got a tolerable one and am picky about location and other things), but the one startup tech job I applied to didn't do puzzles, they did do a screenshared coding portion, but it wasn't a puzzle kind of thing.
- jackconnor 8y ago
  Isn't this all of them?
president 8y ago
"America lacks top notch engineers" - Says every large tech company. It didn't dawn on me until now that, "top notch engineers" really just means "people that are good at passing algorithm interviews". So many people I work with can code every algorithm on leetcode in a jiffy but can't write quality software that works.
- mixmastamyk 8y ago
  The "tech shortage" in a nutshell.
philwelch 8y ago
> previous years of experience, github repos, personal projects, consulting gigs and all other relevant information about your ability As far as evidence for a hiring decision goes, all of the things you listed are things that can either be easily faked, are hard to verify, or require implicitly trusting another organization. How am I supposed to spend the time reading all the code on your github account and forming a judgment of your ability based on that? Even if I do that, how can I be sure that you're the one who wrote that code? How do I know that your previous employers and clients weren't all bozos or that you didn't slack off and let your teammates do all the work? Even if I call your references, they'll probably just say, "yes, this guy definitely worked here, and by HR policy I'm not allowed to say more". Even if they do say more, how am I supposed to trust them? There's not nearly enough information there to make a hiring decision.
- joshwcomeau 8y ago
  > How am I supposed to spend the time reading all the code on your github account Easy - spend the 45 minutes that you had allotted for whiteboard challenges. > how can I be sure that you're the one who wrote that code? You can't be, if the Github account has a single repo with a single commit. But impressive OSS has a history of commits, maybe even a community working with the applicant. As a random example, do you really think it would be possible for someone to fake an account like this? https://github.com/pedronauck https://github.com/pedronauck Even if someone went through the trouble to clone someone else's repo, modify all the commit messages to re-attribute them, and modify the code and commit messages enough to make it not obvious plagiarism, do you really think they could bullshit their way through a quick conversation about the code? Spend 20 minutes digging into it, and then ask pertinent questions about decisions made in the architecture. It'll become clear if this person is the author. It's theoretically possible that someone could put in all the work to pull off a convincing fraud, but do you really think that's likely? > How do I know that your previous employers and clients weren't all bozos or that you didn't slack off and let your teammates do all the work? It's true that there is no perfect signal here, but the odds of this being true are not 50/50. It's not 100% accurate, but having references and employment history is better than nothing. --- To be clear, I don't think OSS inspection is perfect as a hiring tool - it biases towards folks with the privilege to spend their free time working on passion projects - and I'd object to it being the sole determining factor. But I think the signal is far stronger than it is from whiteboarding, where the false negative rate is super high (I doubt most competent programmers would accurately showcase their skill in this environment). There is no perfect hiring practice, but to immediately disregard anything that has even a negligible potential for fraud feels a bit silly to me.

t0mbstone 8y ago

Pretty much all of these ring true for me (20+ years in the industry).

13of40 8y ago

Hand-wringing and debating about how we should use the bug reporting system, triage, sprint planning, user stories, burn-down charts, etc. will keep the leads and PMs busy for decades on end, even if the tools never change.

maerF0x0 8y ago

> That my gender or my age or my ethnicity or my sexual orientation or my weight or my clothes might (will!) have an impact on the perceived quality of the software I build. (Or, in other words, that this is not really a meritocracy, and doing a good job is not nearly enough.) Does there exist any body of proof around this one? Would like to see it and add it to my corpus of knowledge

luckydata 8y ago
go out in the world and pay attention for a few days, you'll get all the proof you need.
deleted 8y ago
[deleted]
lozaning 8y ago
Well I certainly hope I havent been growing out this Unix beard for nothing!
- mixmastamyk 8y ago
  Grey beards no longer allowed at some places, so grab a Just for Men.
Beldin 8y ago
Yes. One typical test is to have people evaluate identical resumes, with the thing being checked for constituting the only difference (e.g. "ethnic" ames vs. "regular" names). Other data points are gathered by studying success at finding internships. A recent study found a rather staggering difference - names indicating local ethnicity got a place in 1-2 letters, while some other ethnicities had to write over 20 (if memory serves). You'll want to find studies for the country you're living in, as the parameters inevitably vary (e.g. which ethnicities to compare). I don't think the outcomes cary much, but i didn't do a comparative study on the literature.
- bytematic 8y ago

tinnet 8y ago

Re #18: It exists, it's called mutation testing, and it's awesome (I only know the Java variant called http://pitest.org http://pitest.org)

epmatsw 8y ago
Stryker is a JS version. Google has some interesting whitepapers about their usage of mutation testing as well: https://ai.google/research/pubs/pub46584 https://ai.google/research/pubs/pub46584
r-s 8y ago
Ruby, too: https://github.com/mbj/mutant https://github.com/mbj/mutant I think most languages have something like this now.

redleggedfrog 8y ago

"That my gender or my age or my ethnicity or my sexual orientation or my weight or my clothes might (will!) have an impact on the perceived quality of the software I build." After nearly three decades writing software, I'd say if that's the case, you're probably at the wrong place. With such circumstances I'd suspect a whole lot of other bad things are probably true, too.

dj-wonk 8y ago
I interpret this comment as saying: if you find yourself in that kind of situation, look around and try to find other opportunities. In other words, life is too short. I also can see the other side: life is often not fair, particularly in the short-run. Life constraints such as geography are real barriers for many people.
- redleggedfrog 8y ago
  You are not only an excellent interpreter, but an astute reflector.

amelius 8y ago

> That the new Altavista competitor would become a less bad Microsoft Office. That the new version of My Space would help damage democracies the world over. And that programmers would get a reputation almost as bad as bankers ...

watwut 8y ago
I think it is more enterpreneurs and startup founders who get all the hate, not so much run of mill programmers.

kenhwang 8y ago

> 8. That having decent people skills makes my technical skills suspect, in the eyes of some. I'm questioning how true this is, especially in today's world of whiteboard interviews and open office spaces. My personal experience seems to suggest that better people skills suggest better technical skill, especially to management.

AnimalMuppet 8y ago
Given the author's name, I think she's female. I fear that, for a female, #8 is more likely to be true than for a male.
danielh96 8y ago
I feel like they might be referring to peers here rather than management
avgDev 8y ago
Not long ago, I failed two sql whiteboard problems and passed 2 c# problems. I was informed by HR that they are making me an offer based on my great people skills, even though I failed their SQL quesitons. I sucked at white boarding(still do because I don't like grinding leetcode before interviews, and I usually make it known). When I first started interviewing I needed like 10 minutes to come up with palindrome solution even though I did it in school so many times. That time I also received an offer. Now, that I think of it I my success rate is 75% and that includes a fortune 1k company. However, it is a pretty small sample size. Now, that I think of it I need to interview more.
watwut 8y ago
I have seen that. I also seen people openly talking about social skills being opposite of coding skills and literally making implications about others. I have seen people pretend lower social skill then they actually have. The most common through is assuming that someone with bad social skills is genius in coding with zero grounds for it. Without seeing code or even talking with those who know his code closely, anything like that. Assumption was that that those people are better in coding because got knows why. I suspect part of it is wish to compensate, but part is stereotype. Open offices have nothing with it, except making people with poor social skills more actively annoying. Which can cancel some of effect I guess.

arkh 8y ago

> why is this not a standard feature of testing frameworks? I want some way to re-run tests flipping some of the assertions, to make sure they are testing what I think they are. That's mutation testing and it the next big thing for tests.

wyldfire 8y ago

> That you can have more than a 100% base salary difference doing the same job, depending on if you work at a small startup or one of the large companies. Even among and within large companies. Somewhat less so within, usually. But one element of that is the (US?) taboo around sharing compensation info.

rco8786 8y ago

> PHP is cool again Come again?

mattmanser 8y ago

Serious question, I've been programming 15 odd years, somewhere around a million people used my code last year, I've written entire sites on my own that happily run today. I don't write tests. Projects that already had tests, those tests caught a single bug in about 3.5 years of working on that code base. Yes, 1 bug. We'd have picked it up anyway when actually testing it. Why do you feel #1 or #16 are actually true? Am I (and colleagues) a magic snowflake, or are tests a massive waste of time, or is it somewhere in the middle?

youeseh 8y ago
It comes down to the cost of failure. If the cost of failure for a particular module say, payments processing or rocket guidance system, is high then writing tests could be much cheaper than waiting for a failure, especially in production.
pathseeker 8y ago
>I've written entire sites on my own that happily run today. This is probably the key issue. You're either working by yourself or you are on small enough team projects that it's easy to recognize when you are breaking things with a change. Tests are about rapidly detecting regressions in a programmatic way. It should not require manually testing every time you want to make a small change to the code base and if you depend on reviewers seeing that a change will break something, you are in for a world of hurt on any large project. Every large project I've been on that has skipped tests has ended up turning into a shitshow where master is broken for days at a time and you can't even tell the cause without hours of manual testing with bisection.
- beokop 8y ago
  > if you depend on reviewers seeing that a change will break something, you are in for a world of hurt on any large project. I don’t agree with this at all. Here’s a counter example: Linux. I think the real problem here is that people don’t take review seriously and/or just don’t care about the project. We build these complicated, expensive systems that do all the thinking for us, not because it’s better, but because we simply don’t care. Having tests is better than letting sloppy developers run amok. In my experience though tests aren’t really needed on projects with a maintainer that actually gives a damn.

jackconnor 8y ago

Frontend programmers are very, very undervalued, I 100% agree. This is because they build the things that your user interacts directly with, where the "rubber meets the road", so to speak. Good FE coders are worth their weight in gold, to any company that has users using their software.

mh8h 8y ago

> 20. That it is all people, all the way down. They are as cute as turtles, but don’t have hard shells. A thousand times this. I used to be amazed by people's intelligence. Now I am amazed by their kindness.

iam_takada 8y ago
This analogy is lost on me. Could you explain?
- BerislavLopac 8y ago
  https://en.wikipedia.org/wiki/Turtles_all_the_way_down https://en.wikipedia.org/wiki/Turtles_all_the_way_down

nraynaud 8y ago

funny how people confuse being told something and integrating it. We're "told" millions of things (more exactly we read all day long), some of it sticks some of it doesn't, it has nothing to do with what we believe is important later in life. I think we have to stop with those things I wish i was told/nobody told me/I would told my younger self. We just decide some points are salient with experience, and I'm pretty sure the list is different after every decade in life.

obelos 8y ago

Regarding #2, I have a harder time switching between touch screen vs. touch pad than I do between text editor key bindings. I seamlessly shift between vi and emacs throughout the day depending on what I'm editing, but put my laptop and tablet side by side and I am forever trying to touch the laptop screen.

watwut 8y ago

That people who write all those cool blogs/talks and people who write good code or manage projects in great way are different in important ways. Meaning what is good tech/code and what is hip on blogs and forums are two distinct groups. Meaning what is good management is completely different then both feel good and look at me I tough bs you find on blogs.

Erem 8y ago

The author was maybe the best engineer I've had the pleasure to work with directly in my 13 years in the industry. What a treat to read her internal thoughts on the job. Highly recommend her other posts on e.g. measuring performance of engineers https://anaulin.org/blog/why-do-we-have-performance-evaluations-anyway/ https://anaulin.org/blog/why-do-we-have-performance-evaluati...

poulsbohemian 8y ago

On this point about testing... what’s still surprising to me after twenty years of doing this is how many errors aren’t technical errors, but rather because someone forgot / failed to document / communicate how something was supposed to work. So something fails, fingers get pointed in the direction of the technical team, but the root cause is all too human.

purplezooey 8y ago

How about: one's abilities count for about 10%, and skill level in high school politics the other 90%.

amriksohata 8y ago

The thing no one told me is the number of requirements folk, like ux, ba's that don't understand their role in agile development and responsibilities in getting solid requirements across to developers

websitescenes 8y ago

Lost me at #13. CSS is not a programming language, nor is it complex..

klohto 8y ago

Article full of hyperboles, without-proof points and self-pity. Doesn't bring anything useful.