201–210 of 395 posts
The constant statusing that doesn't allow one four hours of uninterrupted concentration is demoralizing and grinds progress to a halt. There's a reason more code is authored between 9pm and 5am than between 9am and 5pm, but that wears engineers out badly.
Earlier quoted context omitted.
It's not unusual in the US military for a lieutenant or captain in their early 20s to manage many senior non-commissioned officers in their late 40s.
No mil. experience myself, but I'd say that while the officers may technically 'manage' the NCO's, that with few exceptions it is the NCO's that actually get things done.
Earlier quoted context omitted.
> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. I use this exact description when discussing balancing creative side of the value creation project processes, design and development over the value extraction side of products. Small empowered teams with an almost startup mindset i…
I don't have a lot to add except to say I loved this reply. I think a lot of people might miss it since it's down in the replies, maybe you could expand on it, and make it a blog post at some point?
Good news is there are lots of us like it, the problem is since the value creators rarely control the funding and sometimes lose the power to implement these the right way before internal faction wars start. However at all good product and all good companies, you'll see the respect of value creation and the open mode. One day maybe business/finance will see it with the same value.
A couple of points as well, there is an internal and external view of a product. The external view is really all that matters, the market perception. The internal perceptions and processes if they are made too tight or the main focus, the external product suffers. This is one reason I think remote companies that are smaller, or having small teams, do better. They focus on their external view over the internal. Most remote work is virtual just like most communication today and especially the communication with the people that use products. The external view needs to be the main focus as well as simplicity, but also the "friend" aspect of a product. Using a product should be a simple joy, a friendly part of your day. External focused setups work the best to achieve that.
Earlier quoted context omitted.
I wholeheartedly agree, if you need daily feedback you're a bad manager (unless you're in some exotic situation like a rocket launch or something). This issue largely disappears if your engineers are given the proper context, background and system overview. I'm not advocating everybody should take their project and run with it for weeks on end, but daily updates are ridiculous.
I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to…
Hell, I've fixed 1 liner bugs that have taken me a week to figure out.
Insightful article but surprised at the recommendations. Teamwork is important, yes... but smaller task sizes should have been mentioned too. > Finally, after several weeks, the engineer shares an update, and one (or many) of the following bad things transpire: Several weeks? If you are giving developers open-ended tasks that take weeks or more to complete, imo it's asking for things to go off the rails. The most eff…
I'm currently realizing that laying out a moderately complex PCB can take more than a week, but there's not much to be gained from breaking it up into smaller pieces. You kind of just have to do it.
Of course doing a submarine dive for weeks is never good except to serve as a straw-man for a blog post .
> "the biggest mistake I see engineers make is doing too much work on their own before looping in others" > "For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions. It can also happen if the team culture is toxic and engineers fear getting criticism early in the design process." Not saying the above statement is incorrect but here is an alternativ…
I like writing code. I dislike talking to people.
Earlier quoted context omitted.
I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to…
Thanks for this comment. It pretty much confirms my hunch that I would not be happy in a "developer" role. I have done quite a lot work that requires writing code. But often it has been projects with literally months before there has been anything that anyone might call functionality.
Earlier quoted context omitted.
You are not wrong. I generally sell as a mercenary, and prefer it that way - I've been doing this longer than some of my managers have been alive. I'm paid just as well if they want to "pair program" or jira the whole process, but yeah, you hired me to fix a problem - if you are the problem, I get paid just the same. Welcome to the real world, if your work is interesting, the clock might not turn on when I'm having f…
> If your work is bullshot, I bill tighter than my lawyer Lawyers must hate their work.
Earlier quoted context omitted.
It is better if the managers of technical people are technical themselves. Otherwise you wind up with the Dilbert "pointy-haired-boss" syndrome. The non-technical manager is extremely easy to bullshit, so it's better for the company in almost all ways.
An experienced manager is not easy to bullshit regardless. Sometimes a non-technical manager is better for many reasons. Having business domain experience can be just as valuable
I have encountered technical managers who were not good, for various reasons.
I think having a technical background is always a benefit, HOWEVER, it is neither necessary nor sufficient for being a good manager.