5 ms·

Hard Truths for New Software Developers

41 points by fagnerbrack 7y ago

mrkeen 7y ago
I get the exact opposite takeaway from: > 7. Your evaluative metrics have shifted Yes they've shifted, but the author implies that the success in the workforce needs more rigour than school. It's the complete opposite. Your stuff needs to work in school, and your prof will grade it accordingly. In the workforce, the person 'grading' your work will likely be a product owner who just wants to get the ticket closed. You will hear things like: * "Let's do an MVP." * "Let's focus on the happy path." * "How hard can it be? You're just adding a button." * "Let's close the ticket and we can create a new ticket if we need to." You will not hear: * "This is important, so get it right." * "Your code was wrong. Let's discuss" You'll often be stuck with code that you know is flawed, that you want to fix, but the organisation won't give you time to fix it until it's too late.
- kyralis 7y ago
  If you don't hear "Your code was wrong. Let's discuss." as a junior engineer, you really should try to find a better team. Junior engineer code (hell, senior engineer code!) is quite frequently wrong, and a team with a good code review culture should absolutely be pointing that out and using it as a mentoring opportunity.
- jdsully 7y ago
  Depends on where you work. My time at Microsoft was much closer to what you said I will not hear. There was a parable they used to use in training about how a young developer found a flaw that would only happen “one in a million” times - not worth fixing. An older developer does the math on how many times the feature might run across the total userbase and found we’d be annoying millions of users. Microsoft did have a pseudo hazing ritual where you were forced to setup your own machine. I was surprised how many developers couldn’t do that. I was further surprised that ability to do so wasn’t correlated with skill. Being able to find help if you didn’t know was very highly correlated though.
  - SwiftyBug 7y ago
    Do you mean you were forced to assemble your computer, part by part?
    - jdsully 7y ago
      They were pre assembled from DELL or HP. You had to take everything out of the boxes hook up monitors, etc. The hard part was installing the OS, drivers, and getting your build environment going. One very excellent developer did not know what a driver was. It was that experience that forced me to reevaluate my biases. I had a few friends there in the late 80s/early 90s apparently at that time everyone watched with great anticipation to see if you could figure out the IRQ settings.
  - deleted 7y ago
    [deleted]
- pingyong 7y ago
  >You'll often be stuck with code that you know is flawed, that you want to fix, but the organisation won't give you time to fix it until it's too late. This has unfortunately been my experience as well. Although in some sense I can understand it now. When only ~10k normal people per year use something, the chances of one of them trying to kill it are apparently pretty low. Although I'm still convinced at some point it is going to happen.
cosmiccatnap 7y ago
This sounds like a dad trying to tell his kid how hard it was for them growing up. None of these bullets are a promise and most of them are pretty condisending and seems to just be a rant about all the things that didn't work out for him but that feels like it's because he was expecting to have his hand held alot more which is something I've never assumed.
- diN0bot 7y ago
  I thought it was sweet and helpful. More like a mom telling her hacker daughter what to expect, though. Maybe the culture has changed since you started?
- lol768 7y ago
  >it's because he was expecting to have his hand held alot more which is something I've never assumed If anything I've found I feel more supported at work than I ever did at university. Hand helping? No. But I can ask questions if I've spent a while on something and am totally stuck, we're generally all working towards common goals on projects so we'll collaborate and try to help each other. I also get regular feedback at code review time. Huge contrast to my time at university where for some courses lecturers wouldn't turn up to their own office hours, or answer emails. Useful feedback was generally scarce, occasionally not provided at all and it was difficult to remedy failure.
  - karatestomp 7y ago
    Agreed. Work is in most ways easier than school. If you're lucky enough to find yourself in a highly sane and functional organization (at the level you deal with it, at least) it's life on fucking easy mode. High school's probably the hardest time of my life so far by a long shot, and I'm entering middle age. So, so much work, very little of it of any value to me or to others (and I have a pretty expansive view of what sorts of education are valuable, I'm not a "if it's not part of my narrow field I don't care about it, who needs the humanities" sort), terrible hours, high stress. Even college was easy by comparison—15 hours of classes plus 15 hours of homework and studying (unless you fuck up selecting classes or get unlucky you shouldn't have it worse than that, and may have it much better) and often waking up after the sun rises? Rarely having something assigned one day and due the very next? Practically a vacation! High school was torture and I wasn't even bullied or anything. Worse there were people telling me it's the "best time of my life". No wonder kids are depressed.
gonzo41 7y ago
This is a bit wishy washy but generally scans true. For a newbie 2 and 6 are what I'd consider the main points. 2. You will not get as much help as you need - Because you're the new kid and they are dropping you on a legacy configuration job. Welcome to support baby. This ain't FAANG. You're not getting help because no body knows how to deal with what you looking after. 6. You won't understand everything you're doing And truthfully neither will your peers. Someone will understand saml, they will do the saml and you'll try not to mess it up. Someone will understand the pipeline well, and you'll try not to mess it u. Some will understand the container system etc. My own hard truth: 8. If you write doco it will be something you can show you boss that will set you apart. Writing is hard. Expressing technical ideas in writing is very hard.
- qayxc 7y ago
  > Writing is hard. Expressing technical ideas in writing is very hard. That. I'm always baffled by the amount of positive feedback a well written document or well-structured presentation can get you as opposed to weeks of hard work and craftsmanship that no non-technical person is ever going to notice.
  - finnthehuman 7y ago
    The work that will impress the most is usually found at the boundaries between skillsets, not in the nitty-gritty of one feild. It's the bikeshed problem in reverse. Nobody can understand your reactor design well enough to be impressed by the impressive things you did. They can have their socks knocked off by your bikeshed though. Even if your reactor design would get positive feedback from fellow reactor designers and your bikeshed is a laughing stock among bikeshed builders. Not to say that technical writing is frivolous or lower skilled as bike sheds are to reactor design, this is just the go-to story about approachability.

41 points by fagnerbrack 7y ago

I get the exact opposite takeaway from: > 7. Your evaluative metrics have shifted Yes they've shifted, but the author implies that the success in the workforce needs more rigour than school. It's the complete opposite. Your stuff needs to work in school, and your prof will grade it accordingly. In the workforce, the person 'grading' your work will likely be a product owner who just wants to get the ticket closed. You will hear things like: * "Let's do an MVP." * "Let's focus on the happy path." * "How hard can it be? You're just adding a button." * "Let's close the ticket and we can create a new ticket if we need to." You will not hear: * "This is important, so get it right." * "Your code was wrong. Let's discuss" You'll often be stuck with code that you know is flawed, that you want to fix, but the organisation won't give you time to fix it until it's too late.

kyralis 7y ago
If you don't hear "Your code was wrong. Let's discuss." as a junior engineer, you really should try to find a better team. Junior engineer code (hell, senior engineer code!) is quite frequently wrong, and a team with a good code review culture should absolutely be pointing that out and using it as a mentoring opportunity.
jdsully 7y ago
Depends on where you work. My time at Microsoft was much closer to what you said I will not hear. There was a parable they used to use in training about how a young developer found a flaw that would only happen “one in a million” times - not worth fixing. An older developer does the math on how many times the feature might run across the total userbase and found we’d be annoying millions of users. Microsoft did have a pseudo hazing ritual where you were forced to setup your own machine. I was surprised how many developers couldn’t do that. I was further surprised that ability to do so wasn’t correlated with skill. Being able to find help if you didn’t know was very highly correlated though.
- SwiftyBug 7y ago
  Do you mean you were forced to assemble your computer, part by part?
  - jdsully 7y ago
    They were pre assembled from DELL or HP. You had to take everything out of the boxes hook up monitors, etc. The hard part was installing the OS, drivers, and getting your build environment going. One very excellent developer did not know what a driver was. It was that experience that forced me to reevaluate my biases. I had a few friends there in the late 80s/early 90s apparently at that time everyone watched with great anticipation to see if you could figure out the IRQ settings.
- deleted 7y ago
  [deleted]
pingyong 7y ago
>You'll often be stuck with code that you know is flawed, that you want to fix, but the organisation won't give you time to fix it until it's too late. This has unfortunately been my experience as well. Although in some sense I can understand it now. When only ~10k normal people per year use something, the chances of one of them trying to kill it are apparently pretty low. Although I'm still convinced at some point it is going to happen.

cosmiccatnap 7y ago

This sounds like a dad trying to tell his kid how hard it was for them growing up. None of these bullets are a promise and most of them are pretty condisending and seems to just be a rant about all the things that didn't work out for him but that feels like it's because he was expecting to have his hand held alot more which is something I've never assumed.

diN0bot 7y ago
I thought it was sweet and helpful. More like a mom telling her hacker daughter what to expect, though. Maybe the culture has changed since you started?
lol768 7y ago
>it's because he was expecting to have his hand held alot more which is something I've never assumed If anything I've found I feel more supported at work than I ever did at university. Hand helping? No. But I can ask questions if I've spent a while on something and am totally stuck, we're generally all working towards common goals on projects so we'll collaborate and try to help each other. I also get regular feedback at code review time. Huge contrast to my time at university where for some courses lecturers wouldn't turn up to their own office hours, or answer emails. Useful feedback was generally scarce, occasionally not provided at all and it was difficult to remedy failure.
- karatestomp 7y ago
  Agreed. Work is in most ways easier than school. If you're lucky enough to find yourself in a highly sane and functional organization (at the level you deal with it, at least) it's life on fucking easy mode. High school's probably the hardest time of my life so far by a long shot, and I'm entering middle age. So, so much work, very little of it of any value to me or to others (and I have a pretty expansive view of what sorts of education are valuable, I'm not a "if it's not part of my narrow field I don't care about it, who needs the humanities" sort), terrible hours, high stress. Even college was easy by comparison—15 hours of classes plus 15 hours of homework and studying (unless you fuck up selecting classes or get unlucky you shouldn't have it worse than that, and may have it much better) and often waking up after the sun rises? Rarely having something assigned one day and due the very next? Practically a vacation! High school was torture and I wasn't even bullied or anything. Worse there were people telling me it's the "best time of my life". No wonder kids are depressed.

gonzo41 7y ago

This is a bit wishy washy but generally scans true. For a newbie 2 and 6 are what I'd consider the main points. 2. You will not get as much help as you need - Because you're the new kid and they are dropping you on a legacy configuration job. Welcome to support baby. This ain't FAANG. You're not getting help because no body knows how to deal with what you looking after. 6. You won't understand everything you're doing And truthfully neither will your peers. Someone will understand saml, they will do the saml and you'll try not to mess it up. Someone will understand the pipeline well, and you'll try not to mess it u. Some will understand the container system etc. My own hard truth: 8. If you write doco it will be something you can show you boss that will set you apart. Writing is hard. Expressing technical ideas in writing is very hard.

qayxc 7y ago
> Writing is hard. Expressing technical ideas in writing is very hard. That. I'm always baffled by the amount of positive feedback a well written document or well-structured presentation can get you as opposed to weeks of hard work and craftsmanship that no non-technical person is ever going to notice.
- finnthehuman 7y ago
  The work that will impress the most is usually found at the boundaries between skillsets, not in the nitty-gritty of one feild. It's the bikeshed problem in reverse. Nobody can understand your reactor design well enough to be impressed by the impressive things you did. They can have their socks knocked off by your bikeshed though. Even if your reactor design would get positive feedback from fellow reactor designers and your bikeshed is a laughing stock among bikeshed builders. Not to say that technical writing is frivolous or lower skilled as bike sheds are to reactor design, this is just the go-to story about approachability.