281–286 of 286 posts
Earlier quoted context omitted.
What sort of thing does one make with 1000+ developers?
The same thing one makes with 5. Just really inefficiently.
Feature addiction is exacerbated by VC. Without real consequences to a poorly planned product roadmap due to the years of runway afforded by massive funding rounds, entire orgs fall into the “one more feature” cycle and never focus enough on measuring success in terms of real dollars. No one knows what went wrong when all the money is gone and devs/designers/PMs rinse and repeat at a new well-funded startup.
This actually isn’t true. VCs don’t want companies to build features, they want companies to listen to users maniacally and find product-market fit, then focus on growth (and/or revenue) like mad. That companies focus on features is a management issue and a sign of a failing company, not a sign that VC is somehow bad.
I've never worked somewhere that could actually take a concept to a complete, well-tested feature delivered to users in a two week sprint. I've worked at little startups and a medium-sized tech company as well as FAANG. In each case, we spent most of our time working on projects with 2-3 month time horizons. The small and medium companies called their development strategy "agile". In FAANG we mostly just did our work…
> I've worked at little startups and a medium-sized tech company as well as FAANG. In each case, we spent most of our time working on projects with 2-3 month time horizons. The small and medium companies called their development strategy "agile". In FAANG we mostly just did our work and didn't spend any time on the Kafkaesque exercise of "sprint retrospectives" and "grooming sessions". Our product manager didn't tell…
However, the baseline level of individual competence and motivation is relatively high, which seems to reduce the need for process.
EDIT: the medium-sized company I worked at (~200 engineers) probably falls into the category of "agile hell" you described. The startups weren't as bad.
Earlier quoted context omitted.
A challenge I keep hitting with this is non-technical team asking 'why it takes this long' anytime the provided date is >X (for some X is a day, for others it's a week). They want to understand the internals of the ask so they can then nitpick that "well that's not needed". Fundamentally it's a lack of trust IMO, but any tips on addressing this would be welcome :-)
> Fundamentally it's a lack of trust IMO Which is usually a failure of communication. The whole "just trust us" bit doesn't work, and it takes real work to build a rapport with your stakeholders to earn "blind" trust, which is what most people are really asking for when they say "just trust us". This almost never happens, unless people have been working with each other for many years. > then nitpick that "well that's…
This is interesting and will take some introspection, but perhaps I can improve these situations by fostering better communication. Thanks for taking the time to respond.
Earlier quoted context omitted.
I'm not sure how smart those managers are - I would assume that the best programmers would steer clear of jobs like these ?
Why would you think that? The project manager has communicated well with the client and the requirements getting passed along are correct and full. The developers are specialists in their platform, so implementing the feature is no problem. From experience, it's actually a really nice environment to work in. Everyone is good at their job and you don't have to deal with the clients directly.
Earlier quoted context omitted.
> There must be efforts to refactor and improve existing code Some of the best tech management advice I received was to never get explicit approval for refactoring from your immediate boss - whether you're the line engineer or CTO. Instead, you pad dates as needed to get the refactoring work done implicitly . This has yet to fail me. Granted, I don't work in embedded systems and my code is deployed on owned & operate…
I really push this with my team. I will flat out reject stories that are "refactor". Instead, just do it, and spare us the prioritization debate. If you really can't get it done, you'll find out without eating everyone's time to debate whether you can. And if you get it done, great, things have improved. Now, you will have other priorities. Make sure you aren't dropping them. But most things are communication based.…
Or alternatively, don't, because the message from management is that maintenance takes a back seat to shipping new features.
For example, my team has been using a home-brewed NodeJS-to-Kafka library. Now, everyone on the team understands that this library is suboptimal in a number of ways (most notably because the developer who wrote it is no longer with the company) and that it should be replaced by some alternative from Github. But this is a change that will require quite a few downstream changes (mostly because the way the existing library was used was not well-factored).
There's no way of doing this change without it being a separate story. It's just too big a change. It's also not really something that is easy to do efficiently in an incremental fashion -- having two Kafka libraries simultaneously in the codebase is an even worse situation to be in than having a single, suboptimal library. And management is not willing to authorize a separate story for a "refactoring" such as this one, even though it would result in significant operational savings (less memory usage, fewer server restarts, etc). So we bumble along, waiting until the pain becomes so severe that we're ordered to embark on a hasty rework in order to hurriedly patch in the new library when the system finally melts down.