Letters to Junior Developers • Hacker News Board

Re: Letters to Junior Developers

#31

Post by ejk314 » Thu, Jan 22, 2015, 7:09 PM UTC

vkjv wrote: post #22

nawitus wrote: 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?"

Sounds like a good place to work. But that's in no way typical. At every place I've worked (granted, not all that many) meetings are "free" and when you don't want to be at the meeting you're "not being a team player."

Re: Letters to Junior Developers

#32

Post by datashovel » Thu, Jan 22, 2015, 7:19 PM UTC

onion2k wrote: 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…

Having managed teams before, my feeling is that this advice is good in some cases, and bad in others.

For example, if your team is filled with a bunch of newbies who don't really know what they're capable of yet, their default reaction alot of times is to come to you with their issue. If it happens too frequently it can become counter-productive.

On the other hand, some problems can take a long time just to figure out what's going on, and even more it can be difficult to articulate the issue precisely. As long as the problem is well formulated and precise, progress can usually be achieved by bringing the problem (without solution).

Generally speaking, though, it's good to keep in mind that a manager usually has a ton on his plate already and needs to deal with all his team's problems, whereas the developer is only responsible for working on the one problem.

Final point would be that, especially with younger devs, they can get into a "paralysis by analysis" state. I encourage younger devs to not work on a problem for too long so they're not spinning their wheels. So in these cases I want my younger devs to come to me after they've spent maybe 10-15 minutes on a problem, even if at the end they still don't know what the problem is.

Re: Letters to Junior Developers

#33

Post by datashovel » Thu, Jan 22, 2015, 7:49 PM UTC

yaddayadda wrote: post #25

onion2k wrote: 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.

I encourage the 15 minute rule, but not to just ask help from anyone. Another difficult thing to accomplish as a manager is to prevent unnecessary interruptions for anyone on my team. In an ideal scenario all that stuff goes through me. Not because I want that control. It's because I have the responsibility. One of those responsibilities is to get the most out of my team. So if that means interrupt me instead of your teammates that's my preference pretty much 100% of the time, unless I'm unavailable.

Re: Letters to Junior Developers

#34

Post by [deleted] » Thu, Jan 22, 2015, 10:18 PM UTC

TheCoelacanth wrote: post #30

gharial wrote: 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.

[deleted]