Live data from Hacker News

Letters to Junior Developers

codeovereasy.com

21–30 of 34 posts

Re: Letters to Junior Developers

#21
post #20

Earlier quoted context omitted.

In addition, it pushes company culture to use passion as a hiring signal, discriminating against developers who do not show sufficient levels because they are not "good". In my opinion, this leads to both the so-called "talent shortage" we have now and the underrepresentation of certain groups in the industry. There are far more developer jobs than there are "passionate" developers. Many developer jobs that need doin…

This is definitely true. I've been labeled on occasion as "not passionate" for not being willing to work myself into the ground at 60+ hours a week with a four hour round trip commute. That's not to say that I won't work long hours at crunch time or I have a problem with going the extra mile. But if your "crunch time" is 52 weeks a year, it's no longer a matter of passion, it's just exploitative.

Young programmers can easily be guilted into working 60 hours a week because young smart people tend to be a little naive about how the world turns. My advice to junior programmers is "your recruiters/managers are probably more cynical than you think, understand you better than you think, and manipulate you better than you think".

Re: Letters to Junior Developers

#22
post #6

"Some organizations pretend that they are about other things, like serving people or changing the world. But in truth they are measured by money." And in practice they rarely are not. Nobody calculates the total cost of an unnecessary two hour meeting where 8 highly-paid employees discuss about something almost completely irrelevant. Another problem with this is that it's extremely difficult to calculate anything whe…

"And in practice they rarely are not. Nobody calculates the total cost of an unnecessary two hour meeting where 8 highly-paid employees discuss about something almost completely irrelevant."

In my experience, that is absolutely not true. Just about any meeting I've ever been in with more than 6 people, the very first question was, "this meeting is expensive, does it need to happen and do we need everyone?"

Re: Letters to Junior Developers

#23
post #22
post #6

"Some organizations pretend that they are about other things, like serving people or changing the world. But in truth they are measured by money." And in practice they rarely are not. Nobody calculates the total cost of an unnecessary two hour meeting where 8 highly-paid employees discuss about something almost completely irrelevant. Another problem with this is that it's extremely difficult to calculate anything whe…

"And in practice they rarely are not. Nobody calculates the total cost of an unnecessary two hour meeting where 8 highly-paid employees discuss about something almost completely irrelevant." In my experience, that is absolutely not true. Just about any meeting I've ever been in with more than 6 people, the very first question was, "this meeting is expensive, does it need to happen and do we need everyone?"

In my experience, it is absolutely true.

And I worked at really small and really big companies.

No one thought about the cost of a meeting, they thought of them as a normal thing every company does for a few hours a week.

Re: Letters to Junior Developers

#24
post #21
post #20

Earlier quoted context omitted.

This is definitely true. I've been labeled on occasion as "not passionate" for not being willing to work myself into the ground at 60+ hours a week with a four hour round trip commute. That's not to say that I won't work long hours at crunch time or I have a problem with going the extra mile. But if your "crunch time" is 52 weeks a year, it's no longer a matter of passion, it's just exploitative.

Young programmers can easily be guilted into working 60 hours a week because young smart people tend to be a little naive about how the world turns. My advice to junior programmers is "your recruiters/managers are probably more cynical than you think, understand you better than you think, and manipulate you better than you think".

Ah yes, passionate and naive is an awesome combination for exploitation.

Re: Letters to Junior Developers

#25
post #9

I really don't agree with the final "Present a solution, not just a problem" point. Quite often a developer will be able to see a problem but won't have a clue what the solution is. Having a "Present a solution, not just a problem" approach means that developers won't want to inform you that the problem is there, and then it'll surprise you later at the worst possible time. If you have a solution, great. If you don't…

I'd modify it to "Don't present just a problem, present a solution, or all the solutions you've tried and why they didn't solve the problem."

I've also heard some companies have time limits on seeking help, e.g. if you're a junior developer and can't solve the problem on your own within 15 minutes, ask for help.

Re: Letters to Junior Developers

#27
post #3

Great advice! I would agree with everything except maybe that “I just had to hack something together…” always is a bad thing. Especially from the business point of view this article stresses, it can be reasonable to 80/20 your way out of certain problems and then polish it in the future.

Thanks for this comment. I kind of feared saying something like this would be begging for down votes, but I'm glad I'm not alone. I truly believe that a good developer knows how to strike a balance, and if he/she wants to be a hero to the team, sometimes a hack is better than stressing out 4 other people because you are insistent about adhering to an architectural pattern in the face of a looming and important deadline.

This has been a major point of contention for us recently with team members that can't distinguish 'urgent' matters from 'important' ones.

Re: Letters to Junior Developers

#28
A lot of this is really wonderful advice, though I disagree somewhat on one point.

The good stuff first - I completely agree that a developer should look at a maintenance project as a learning opportunity. I was lucky enough to get a lot of researchy, green field projects early in my career. But I grew a lot as a developer when I started maintaining, adapting, and modifying an existing code base. My only real caveat here is that it should be a relevant project, ideally an open source project. You'll be introduced to a lot of different developers, and you'll get a really good sense of how to work collaboratively with a lot of different people. There is a huge difference between a project that says "there's an existing open source app - it's reasonably well written, but it needs work and updating, and we need some new features" and "here's stan's old pile of crap, keep it running." The first can be a huge learning experience and great for building a network and career. This is the sort of experience that gets you to a point where you may be able to get new programming jobs without 3 references and several hours at the whiteboard showing how to find a cycle in a linked list. A lot of people know you because they have worked with you, and they know your code because, well, they've reviewed your code and you've reviewed theirs. It really is a way to rise above some of the unpleasantness of our industry.

Now for my disagreement. "Do this job because you love it." I'd be ok if we added the phrase "as the thing you do for money." I don't think you need to love programming so much that you'd do it even if you suddenly had 10 mil in your bank account. That may be an unrealistic standard.

Re: Letters to Junior Developers

#30
post #10

Nice writeup, with the exception that you should never, ever "love something so much you'd do it for free" in a professional setting. I get that the intention behind the statement isn't literal, but that kind of attitude is what makes hiring managers think that they can make junior developers sub-25k offers in places like Manhattan. I had the confidence to never allow myself to be low balled and quite enjoyed the lec…

I would develop software even if I didn't get paid for it, but I wouldn't develop the software that other people want developed.
Post reply on HN