41–50 of 63 posts
The real way a senior engineer trains juniors is by selecting appropriate work. They thread the needle of a number of factors: it needs to be done, its within reach, will build their skills, will educate them on product/business/process, they will find rewarding, will give ownership, relevant staff can support them etc. These factors are so important that the senior engineer might need to negotiate with the product m…
This article works in theory, not so much in practice. The theory is fine, it's the reality of working in the real world where it is less fine. I think the author needs to rethink his approach in the context of a limited budget. If your goal is to grow your junior engineers at any cost, great article. If your goal is to balance the benefit to the company/project with growing a junior engineer, less great. And perl? F…
I saved this comment from jlcfly from an AskHN that was answered a long time ago and have reposted it many times, as I feel it is an excellent philosophy for making your team better. "Teach them to be better than you. That may seem counterproductive. I have a type A personality, and I have decent coding skills. I've been in your situation a number of times. I also know there's these mythical expert developers out the…
> I know this is a "do what I say not do what I do" situation, but please X because we've had problems with Y.
Senior engineers are, by definition, survivors in the engineering trade. We weren't driven out to open pizza shops or become midlevel product managers. Most of us senior engineers have made our share of mistakes. We've had people help us understand and correct our mistakes. "rollback!" The job of any engineer is to work ourselves out of every job, so we can do other jobs. Our job as senior engineers is this: give jun…
I always wonder why waste the best and most creative years of young people at school teaching them things that they will not use in real world work environment. Is it not much better if the novice programmer enters the work environment without going to school first and learns the job by doing?
I especially object to the academic way of teaching a subject which requires the student to learn the whole field before issuing him a license to practice. This is like teaching someone who wants to tend to his small garden the entire science of botanics and require him to know all the plants in the world before allowing to play in his backyard garden.
Sorry for off-topic comment.
Earlier quoted context omitted.
I have landed on the phrases rising tide vs shooting star. Early in my career I wanted to be the shooting star, the bestest most productive person there. Now that I'm older I want to be a rising tide that raises all ships. Did you experience a similar transition, or were you always a rising tide type?
Yeap. I was the most productive in the room and it was becoming a problem. Others simply couldn't keep up and it was slowing us down on the long run rather than making it go faster and better. I was disappointed with the improvements others in my team were making and started wondering what I could do to make that go better. I realised that one of the freedoms I had early in the career was the freedom to experiment an…
>Yeap. I was the most productive in the room and it was becoming a problem. Others simply couldn't keep up and it was slowing us down on the long run rather than making it go faster and better.
It was a problem for me too, but in a different way. I feel like I was resented by my teammates for being a shooting star. I was younger then so there's a strong possibility I was hot-dogging it a bit unintentionally. I was definitely getting first pick at all the coolest projects, which of course I enjoyed.
I'm not entirely confident that more is being accomplished now that I'm a rising tide. Statistically I think there's some evidence that isn't the case. For example, there's Price's Law which states that half the productivity is completed by the square root of the people in the domain. The following is really rough math just to put some plausible numbers on it... So if there's 9 people on the team, I was one of the 3 people doing half the work, and the other 6 did the other half of the work. That means I was individually accomplishing 16.6% of the work, and the 6 were each accomplishing 8%. If by being a rising tide my individual productivity is cut in half, then the other 6 people have to improve their individual productivity by nearly 3% of the total work, or 35% over what they were doing before. I have no confidence that the other people have improved their productivity by 35%. If I could reliably improve worker productivity by 35%+ I'd be a lot wealthier. However, I do believe people enjoy working with me more, and consequently I have a better experience at work.
With the landscape constantly changing you could argue if we take too much weight on senior perception. For example: "Those 10GB of data would take up too much space, it's BIG DATA, we can't afford that!" ... Junior: We could use my laptop, it has 2 TB.
At a higher level though, I can't help but feel our industry is taking so long to mature because everyone has to keep making the same mistakes over and over and we don't learn from history.
Conversations often go like:
Engineer A: "I'm going to do XYZ".
Engineer B: "Hmm, we've tried XYZ, it exploded in our face"
Engineer A: "I've had experience with XYZ on my side project/little startup, it works fine!"
Engineer B: "Yeah, it works at first but eventually problems arise and it will blow up"
Engineer A: "Whatever, I'm doing it anyway"
Engineer A: "See, it worked fine!"
Engineer B points at the beggining of some problems
Engineer A: "That's normal!"
Engineer B: "Welp, as expected, it all went to hell. Where's Engineer A?"
Engineer C: "Oh, Engineer A got bored and quit/joined another company. Looks like you're inheriting it, Engineer A!"
Repeat...hundreds of times...for everything.
In my experience, typically the junior's suggestion can possibly be done. However it often would be complicated to implement well, and I would be concerned how long it would take the junior to complete (if they would complete it satisfactorily at all). So, I agree with the suggestions that it is often more productive if a senior engineer suggests appropriate work.
Which is not to say that there shouldn't be clarity in terms of who gets final decision making or that there is no hierarchy at all. But in most discussions you should treat them as a smart person who probably has good ideas that should be respected. Otherwise why did you hire them? I'm not _quite_ getting that tone from this article.
My thought is that really good juniors need to be treated as less experienced peers in most (but not all) interactions. A smart, hard working, capable programmer is going to need to feel respected. So the number of times 'junior' and 'senior' get thrown around here is problematic. Which is not to say that there shouldn't be clarity in terms of who gets final decision making or that there is no hierarchy at all. But i…
I interact with people daily who are far more "senior" to me on specific topics, and I to them on other topics.