Hacker News Reader

Comment by emodendroket | Hacker News Reader

I don't think someone necessarily has to live and breathe code to be good at their job. That kind of focus is hard to maintain forever. When I was new I was constantly reading programming books and now, like, I'm still interested, but other things are going on in my life that also need my attention, you know?

View on HN

You can lead a horse to the water but you can't make him drink.

It's completely okay to "just" do your job professionally. However, skill development, transfer of skills to junior developers and mentoring is a different issue - if you want to learn from me, you have to want to learn; if you're just here for the paycheck, then I'm not going to go out of my way to educate you even if (which is the case for many junior developers) you're unable to actually do your tasks properly on your own without this help.

People with the desire and capacity to learn go over the "junior" phase very quickly (over a short internship or already during college) and become able to do decent work on their own; but those who don't and really need an actual prolonged "junior developer" role on the team... there's no incentive for the employer to do that, and there's no incentive for the colleagues to spend their effort if it seems wasted on someone who's not into it.

I can see your perspective. I think we're kind of talking at cross purposes here. I think it's reasonable to expect someone who needs mentoring to pay attention and want to learn. What I don't like is this idea that you need to spend every waking hour on programming or you're just a clocker who has nothing to contribute to a serious team.

This. Mentoring should just be pointing people in a direction and occasional code review. Go do this (for a few days). Let's see what you did. This is good, this should be that, name your variables better, etc.

If you let juniors figure it out the hard way, they will learn better, or they will fail. If they fail to learn by themselves, they will never become senior.*

*Shitty code bases should be given a lot of leeway on the learning curve.

> Mentoring should just be pointing people in a direction and occasional code review. Go do this (for a few days). Let's see what you did.

That's one (totally fine) way of mentoring, but it's by no means the only one.

A lot depends on the work environment and the relationship. I work with a couple junior engineers that are also friends, and in addition to "pointing people in a direction", code reviews, etc.:

* We frequently tackle harder issues together, pair-programming style (using a shared tmux session)

* In addition to code-reviewing their work, I have them code-review mine, and I walk them through my code and thought process

* Talks/meetings once a week or more about architecture/up-front design for projects, in which the junior devs are often included or free to attend

* We have a non-work-related Hackerspace that we attend every 2 weeks where we work on side projects / fun creative projects

Certainly this situation is not possible on many development teams, but I just wanted to point out that mentoring is a wide-open thing that has many approaches and options.

You can be willing to learn and still have work/life boundaries.

Absolutely - trying to teach people who are not interested in learning requires a very special set of skills, motivation, and personality that few have IMO. It certainly demoralized me as my university teaching responsibilities gradually shifted from small graduate research seminars to overcrowded introductory undergrad surveys, and now in tech roles I make sure to push back whenever my job devolves too far into babysitting. Smart, motivated junior devs are a true pleasure to work with, but unfortunately are still the exception rather than the rule.

I don't think you need to spend all your spare time making side projects or learning new technologies, but I do think a certain amount of professional curiosity is required as a software engineer, just like any other programming job.

I'll probably spend 15-30 minutes every day outside of work reading about new things, or tinkering around with something, even if it's just reading Hacker News, often these things I learn end up being used at work, so I gain new skills at work. It sounds like you're in the same boat.

My father is a network engineer, and he'll spend time in the evening doing things related to his field, he has a very impressive home networking setup. My friends that are electrical engineers play around with electronics in their spare time.

I think that for any professional, to be successful and have a good career you need to have at least some outside interest in your field. Obviously we all have hobbies, I don't sacrifice those because of work, but if you're working in a job where you have no interest you'll never get far.

I don't live and breathe programming either. But when I am at work I care about the technology and like to learn new stuff whereas a lot of people I see just do what they are told to do and take their paycheck home. Nothing wrong with that but I find it more fun to work with people who care.

OK, fair enough. I agree with you; I also like to challenge myself with new things. But I like to go home at the end of the day too, you know? Sometimes I think programmer culture gets too self-flagellating.

I hate the whole side-project-after-work thing. Unless you have a real business idea to pursue I think 40 hours per week of focused work is plenty. There are a lot of other cool things in life.

Yeah, that's exactly what I'm getting at.

I agree completely. But in a vacuum, the developer who codes outside of work probably has more knowledge and experience than the developer who works 40h/week and goes off to other things. Even considering diminishing returns.

Yes and no. I think somebody a little more well-rounded may have other soft skills that are also important.

Yeah that's true, hence in a vacuum. If you want someone to do nothing but code - the person who codes the most often will take the cake.

You almost never want that though. Every job I've ever done involved communicating with stakeholders and team mates, working out requirements, resolving disagreements, etc.

My time spent on side projects went down close to zero just about the time I graduated and became employed full time working 40-45 hour weeks.

I don't see any problem with that though; I'm still learning a lot, and work towards switching projects/companies when that's no longer the case.

I think there are a handful of other reasons to persue a side-project-after-work, but mostly they'll be highly self-motivated and individualistic. That's not a bad thing; it may just mean that it's not going to be something you spin into a business, but it's something that solves a need in your life, and as such you don't take very seriously.

If it means you're still learning something a little extra, that's great! If not, that's okay too.

Yes, for me it's up and down. I do side projects a lot more when I'm sick of the company I'm at. Trying to get out of the grind.

I can completely relate to this.

> When I was new I was constantly reading programming books and now, like, I'm still interested, but other things are going on in my life that also need my attention, you know?

It's not a binary thing. The fact that you were/are interested enough in technology in the past is different than someone who only did the bare minimum. I consider it more of a mindset thing.

Reply on news.ycombinator.com