As someone with people who report to me, my #1 job is to make sure they’re effective, happy, productive. Empowering them generates more productivity than me quietly doing stuff myself.
If you have people who report to you and your main job is enabling them, you’re a manager not an engineer. Which is fine, but also it’s an important distinction to make.
Labelling someone “engineer” or “manager” is not really useful. So why go out on a perilous precipice of doing so, especially when one lacks almost all the details necessary to make an informed assessment?
I think its pretty useful distinction. I know everywhere is different, but everywhere i have worked the roles have been very distinct. Engineers, especially senior ones, mentor people of course, with that being a significant part of their job, but that is really different from having someone report to you.
My previous contract ended abruptly but then a month later they needed me again because their current onshore offshore team was very large and growing by the day but incapable of non-trivial engineering tasks, all the way up to the engineering managers. They were essentially the hire paid copy/pasters. I said I'd return under the condition that I will golf all day. They hired me back on, I made the thing they needed, then they dumped me again abruptly for another onshore offshore engineer.
So sometimes a headcount can be an engineer, a manager, or both, and still be an embarrassment to git commits everywhere.
I entirely disagree both with this point and with it’s apparent subtext that being an engineer is better and being a manager is worse. I take it that you are one who takes great pride in “being an engineer”. That’s a separate topic (for instance, one can be an engineer in a management job).
We have the abstraction of job titles or categories to help us reason about what a job is. We do this for a variety of reasons, but in this case the reason to do it is to help people understand whether this advice might apply to them. Ultimately, a job is whatever it’s primary goal is, and you said yours is to empower junior staff who report to you. That makes you very different from many (most?) senior/staff engineers I have met, who are primarily metric’d on their engineering work. Since your primary job is a management function and you write a lot of code, that makes you a manager with some (or many, pick whatever modifier seems appropriate to you) engineering responsibilities.
Bringing it home, if a reader is an engineer (or IC if you prefer to avoid the fraught term) and not a manager, this advice doesn’t apply to them very strongly. Yes they should care about junior colleagues, and they should absolutely make time for deliberate peering and mentoring, but they should focus on doing engineering (which can include docs writing etc) primarily.
Sure, but is constant "direct attention" the best way to empower engineers? I would argue that systemic improvements (e.g. onboarding process, good documentation, team communication or company culture) are more impactful since they scale better and address the root of the problem. Of course, you need both, but saying that everything other than hand-holding is "just filler" shows a lack of understanding of good leadership.
I have people that report to me. This is true a lot of the time. The other thing I do is getting people to use the thing my team built - or figuring out what they want my team to build.
It’s not, if your job is to onboard a new engineer. Those first few months make all the difference. If the “other parts” of your job prevent you from maximally optimizing the productivity of your new coworker, the compounding negative returns on that onboarding engineers time is incredibly expensive.
Unlike almost anything else you could be working on, turning someone from nonproductive to productive, or more productive, has compounding effects that can quickly help or hinder the longer term objectives
Agree. At the end of the day, someone is paying for the jr and sr person. Is that what they want? If so, then it is fine I suppose. They do need to state this clearly however.
Yes, but here comes the problem: where would I send this request? Instagram notes no public facing physical address for my country and their support e-mail just sends back automated replies.
I would send the request both online and by tracked post with a proof of delivery. In the end your lawyer would do the same thing and charge for this at an hourly rate.
The automated ID verification might fail for a variety of reasons (frankly if they don’t originally have a copy I’m not sure what they’d be comparing it to) but the GDPR process should work if you fight long enough. You might need to prove that you owned the email or number though - email might be tricky but number is easier as you can submit a bill or do another subject access request to your provider which should still have records about it.
> No other smart watch had that feature, and (almost) no other smart watch has it today in 2022.
That's not really true, unless your definition of a smartwatch is limited to Apple/Android devices with LED displays. I use Garmin Fenix with a transflective display which lasts about 2 weeks on a single charge. However, like with Pebble, there are some tradeoffs: the display is not as bright (but clearly visible in the sun), it has less colors, and the screen resolution is lower.
I know this is just an anecdote, but a good developer wouldn't ask the manager to approve every small refactoring or expect them to understand the importance of "one method in SuperFactory". They would have instead made a judgement call and taken the responsibility of doing the quick fix.
> wouldn't ask the manager to approve every small refactoring
It becomes an issue if it takes more than a day. Scrum, Kanban, RUP, XP, waterfall - whatever "methodology" they say they're following, it boils down to "tell me how long this is going to take and I'll check to see how close what you said was to the time it took". If you can make a change in an hour, sure. If it takes a day, it's going to break your "commitment".
Except in XP the developer will refactor before and after implementing the feature, the customer doesn’t get to say how things get done, and there is no “manager” role.
Not to say that people don’t operate completely differently and call it XP. That’s always a problem. But it isn’t “No True Scotsman”, it’s literally just not following the recipe and expecting the cake at the end.
Or... Management could choose not run their software development organisation with the kind of micromanagement strategy that requires everything to be allocated in units of one day or less. It's another red flag that has become disturbingly common in the industry and suggests managers more interested in "visibility" and "metrics" than actually doing a good job, sustainably, by trusting their technical people to do theirs.
I love how "story points" aren't supposed to represent days, yet conveniently everyone winds up with 10-ish over their 2 week sprint, and it is totally micromanaged. Meanwhile none of the non-technical "product people" are ever asked to account for their time like this.
While I agree with you, some managers micromanage and freak out for any change that isn't directly related to doing or fixing X. They will reject the change and it becomes painful to keep working like that because they hold it against you. Toxic workplaces exist.
And in a market where developer skills are in incredibly high demand and a new job can be lined up in a couple of weeks, such workplaces should cease to exist due to lack of developers.
To the average hackernews, lucrative tech jobs may grow on trees, but that is not the case for everyone, even those with technical skill. It usually takes me between three and six months to get a new job.
Yes, the general rule for me is if I see something completely whack on the ticket I'm working on, I'll clean it up as long as I know there won't be collateral damage. The problem comes when these systems become so complex and so old and the people working on them don't really know what changes will affect other systems down the chain.
IME in SAFE® Agile™ world developers are fully empowered to not take decision on things which are domain of enterprise architects/ Product manager or leadership calls.
