When the author says “use modern techniques like forecasting” in the section on estimation, what do they mean, specifically?
How to drive away your best engineers
291–300 of 316 posts
Re: How to drive away your best engineers
#292Earlier quoted context omitted.
> have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. I sympathize with the other comments explaining that Git is highly nontrivial, but I think the point is being missed. Why should I have to teach a junior how to use an essential tool of the job, when I can just point them to good books/guides on the Internet? My list would definitely include: Hire people who can and are w…
> Hire people who can and are willing to read. Also make sure they are able to read more than the first few words of the first sentence…(from bitter experience)
Reading is a huge problem with certain developers.
It's not only documentation, which they ask for but never read. They also won't read error messages, and ask seniors for help on almost every situation.
(But the most infuriating thing is when they assume the error message doesn't have any info, and when sharing the screen you have to repeatedly ask them to not navigate away because you're reading it)
Re: How to drive away your best engineers
#293Not included in this list but definitely worth mentioning; - Lowering your hiring bar. When you hire people the burden to get them up to speed and productive is on the existing team. If these people are smart and motivated, great! But no-one benefits from having 200k+ engineers now have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. - Not involving your current team in decis…
An interesting sociological question arises about how knowledge is passed down through generations. One could count the number of software engineering management tenets on one hand. One of them was detailed in a popular book almost a half century ago. If managers haven’t heard of the Mythical Man Month, how can one have any confidence at all about any of their decisions. Is management a knowledge-free profession?
I knew a CEO that claimed that Mythical Man Month was his favourite book.
As soon as it was decided the team was late (due to constantly changing scope) he put forth a plan to make the team 4x bigger in one year. Contrary to probably the most obvious lesson from the book.
People just don't read. Or admit THEY are at fault.
Re: How to drive away your best engineers
#294Earlier quoted context omitted.
> Hire people who can and are willing to read. Also make sure they are able to read more than the first few words of the first sentence…(from bitter experience)
Reading is a huge problem with certain developers. It's not only documentation, which they ask for but never read. They also won't read error messages, and ask seniors for help on almost every situation. (But the most infuriating thing is when they assume the error message doesn't have any info, and when sharing the screen you have to repeatedly ask them to not navigate away because you're reading it)
> (But the most infuriating thing is when they assume the error message doesn't have any info, and when sharing the screen you have to repeatedly ask them to not navigate away because you're reading it)
Oh yeah - this drives me nuts, although I've seen it more from laypeople than developers. Some people are hard wired to just hit Enter for any informational window that pops up on the screen. I've talked to people who have no idea they're getting errors: "I just hit Enter so I can get to the program."
Re: How to drive away your best engineers
#295Earlier quoted context omitted.
> Why shouldn't you? Because I expect people to have basic reading and Internet searching skills. As I mentioned elsewhere, I don't have a problem mentoring them on what skills they should learn. I also don't have a problem directing them to resources where they can learn - even telling them what to focus on and what not to focus on. But I expect that once I point them to a resource, they'll go and read it. For thing…
> Put another way: If you were my boss, would you want me to spend my time teaching the same basic Git usage to every junior hire? I guess I think it depends. I think some companies absolutely do need to take this on, hiring very green brand new hires and investing a large chunk of their more senior engineers' time into showing them the ropes. How else would it get done? I don't mean only for this specific example of…
> I don't mean only for this specific example of git usage, but every entry level employee - whether from a college program or a bootcamp or self taught or whatever else - is gonna have a lot of gaps,
That's understandable - the issue under contention is how to address the gap. I absolutely do not expect people to know Git when they start. If you look at my comment history, including in the last few days, you'll see that I dislike Git and think there are better alternatives.
The issue is: Once a gap has been identified, and there is plenty of documentation/resources out there, why is it not enough to point them to it? Why is it not enough to have a Wiki page listing all the tools they're expected to know/learn, with guides to resources to learn from? If there's a specific, obscure or internal tool with poor docs, I can understand spending time with each hire. But should a developer always teach:
- How to use Git
- How to write makefiles[1]
- How to do regular expressions (including teaching the syntax, etc).
- How to use a standard shell (bash/zsh/csh/tcsh)
Larger companies often have senior folks teaching courses on these, which I like. My complaint isn't that these courses shouldn't exist. It's that with some employees, directing them to the course simply doesn't seem to suffice.
I think the role of mentorship by senior folks is more for :
- Teaching them certain design principles/patterns
- Pointing things out during code reviews
- Teaching how to test things well (I still haven't found a single good resource for this).
- Teaching when to shun/embrace complexity
- What they should learn/focus on (e.g. identify strengths and weaknesses, and how to overcome weaknesses).
And so on: Basically things that are mostly gained out of hard experience or that are undecided (i.e. differing opinions in industry - senior giving his/her take).
But certainly, if there were books/resources that unambiguously teach items from the above, I think a junior employee should be given that resource and they should learn.
(And by learn, I mean on the job, on company time).
[1] Although I'd used makefiles to compile tools for over a decade, I never learned the syntax. Then for one job I needed it. No one would teach me it. It's a heavily used tool and it was understood that I should just read the Make docs. I didn't think it unreasonable. -
Re: How to drive away your best engineers
#296> Stop estimating. I have analysed every team I have been on that use estimation. Those teams have been 99% incorrect. In my experience, it does not work. If you need dates, I would recommend a more modern approach like forecasting. What does this even mean? I've never heard of a forecast that didn't use a combination of past data and an assessment of complexity of future work to assemble the forecast. And assessment…
I think the difference is that a forecast is developed by a team (or formula/ML) separate from the engineers doing the work.
Once again: no team or model or formula can produce a forecast without an assessment of complexity for the work effort being forecast.
So if what you're saying is true, this would involve someone other than the devs assessing complexity, then coming up with a date, and then holding the devs accountable.
And that sounds like a complete nightmare that's far worse.
Re: How to drive away your best engineers
#297Earlier quoted context omitted.
> the best engineers can pick and chose Sorta. I would take a less-qualified but more personable engineer over their more capable peer any day of the week, for the aforementioned reasons: engineering isn't the only skill required – those who don't insist on managerial perfection don't actually need a lot of managing as a result. It's a positive feedback loop. Also if engineers think we don't check references and back…
You're doing a lot of assuming that the engineer seeking greener pastures because they are, I don't know "selfish" or something, is easily detectible. I can confidently tell you that you're operating under self delusion. Also assuming that someone who isn't going to tolerate fuck-fuck games with assholes when they don't have to is themselves an asshole. It's entirely possible to amicably end a relationship with someo…
> I can confidently tell you that you're operating under self delusion.
Confidently incorrect! It's the iron law of the market; I don't make the rules.
Fwiw, bureaucracy used to not be such a pejorative term; it implies coordination at scale, with internal checks and balances. Engineering doesn't happen without talent, talent needs money, money comes from good sales and marketing, etc.
To be efficient, these things have to be centrally coordinated by an entity that typically has an eye on the market, which behaves beyond anyone's control.
Re: How to drive away your best engineers
#298Earlier quoted context omitted.
> the best engineers can pick and chose Sorta. I would take a less-qualified but more personable engineer over their more capable peer any day of the week, for the aforementioned reasons: engineering isn't the only skill required – those who don't insist on managerial perfection don't actually need a lot of managing as a result. It's a positive feedback loop. Also if engineers think we don't check references and back…
if engineers think we don't check references and backgrounds anymore – including reputation – those days are long past How do you check reputation?
Word of mouth, mostly.
Re: How to drive away your best engineers
#299Like many engineers, the author of this article assumes all engineers are ethical, and perfectly suited to the assigned task. The author also assumes unlimited budgets, perfect control over a company's hiring and resource management, and a perfect understanding of the software's requirements. These are the same complaints I hear from inexperienced engineers over and over and over again – and not just engineers, but a…
Agree re the article, disagree re labor vs management. This mentality in an org is almost always a result of mismanagement. The reason is obvious: it's a people issue and dealing with people issues is a managerial responsibility. Thinking that managers are bad in general is only a sign of inexperience because it implies someone has never worked in a place with good management before. I've seen plenty of "fuck managem…
Completely agree that it's on management to foster a great place to work. I put scare quotes around 'labor' and 'management' because they're really nonsense terms.
I'm a big believer of culture coming from the ground up; you can't design it, you can only help it grow with good soil, water, and food.
Re: How to drive away your best engineers
#300Earlier quoted context omitted.
> the best engineers can pick and chose Sorta. I would take a less-qualified but more personable engineer over their more capable peer any day of the week, for the aforementioned reasons: engineering isn't the only skill required – those who don't insist on managerial perfection don't actually need a lot of managing as a result. It's a positive feedback loop. Also if engineers think we don't check references and back…
You're doing a lot of assuming that the engineer seeking greener pastures because they are, I don't know "selfish" or something, is easily detectible. I can confidently tell you that you're operating under self delusion. Also assuming that someone who isn't going to tolerate fuck-fuck games with assholes when they don't have to is themselves an asshole. It's entirely possible to amicably end a relationship with someo…
[deleted]