Hard Truths for New Software Developers | Hacker News Reader

Hard Truths for New Software Developers

hackernoon.com

41 pointsfagnerbrack17 comments

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.

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.

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.

Do you mean you were forced to assemble your computer, part by part?

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.

>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.

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.

> 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.

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.

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.

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?

>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.

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.

For me, HS was easy and college was brutal. But I agree that short of a startup, work is much easier and should be.

I didn't get that from the article. As a 15-year engineer who turned manager I would say the list sounds pretty reasonable. The biggest problem, which the article mentioned, I see with junior engineers is the inability to see the "product" over the "code". They want to "correct" the code and the stack but fail to weigh whether that actually improves the product.

Have to agree something about it sounds very off.

I think the main issue is that it is written in such a passive way as if these things are reality and there is nothing you can do.

Everyone of those issues can be fixed relatively easily by being a bit more assertive.

What I really dislike is this idea that nothing is possible without being in a team. It’s so wrong.

Sometimes I wonder who this kind of advice is written for. What kind of attitude or perspective does someone need to benefit from this advice? How much of it is written for the author to say it versus someone to find it useful?

I think back to the people in my major who had obviously never had a higschool job, nor worked on a project that required them to engage in problem solving (outside the highly structured and guided problems in school assignments). Most of them figured out what work is, bombed out, or gave up. A few were still around in senior year, having found new ways to skate by.

People are under-served by the systems we shoot kids through. And my criticism is not in the typical "we don't train for X" way. Not only are there infinite X's, but the system creates expectations and boundaries that adding more Xs just entrenches. A person can be perfectly competent at some set of tasks, able to be trained on others but still see everyone (including themselves) as cogs in a finished system solved by the smarter people.

What I'm getting at is the lack of insight that lead to the time a friend of a friend saw my roommate watching a youtube video on the TV of something being built and asked "Why are you watching this? Just buy one at the store." At the time, that statement was as bewildering to us as it was bewildering to them that there could be value and entertainment in watching and understanding the process.

Reply on news.ycombinator.com