that's a good point, however maybe the difference is that kilo is not creating a situation for themselves where they either have to reprice or they have to throttle.
I believe it's pretty clear when you use these credits that it's temporary (and that it's a marketing strategy), vs claude/cursor where they have to fit their costs into the subscription price and make things opaque to you
self driving cars are only good for city built around cars.
I was in Marseille - France - last week and a driverless car would not drive more than 100 yards there before being stuck
The poor people living in Boston live in Roxbury and Dorchester. Coincidentally, these are the areas with by far the worst car dependency and worst public transit in the city.
Apologies, I was basing my take there on having biked through most neighborhoods and witnessing the worst traffic by far in those areas, so it certainly feels as though the car density is the highest. (It's also the only place I've ever been hit on a bicycle, and then had someone behind me get mad for being in the way while I was picking myself back up)
That sounds awful. Impoverished areas are well known for lacking traffic calming measures leading to higher pedestrian and bike accident, this is certainly true in my home city of DC.
On the flip side, Boston is the only city where I've ever hit a car with my bike.
I think the engineering management field is going to drastically change in the next 5 years (probably 2 but industry will be slower to changes in some areas). We are already seeing signs at companies like Twitter and meta.
Coding is a poor use of time given that it runs counter to context switching required of management. If you see someone suggest this you should make that clear. Anyone with a decent amount of experience could help back this point up should you encounter someone trying to push for this.
There's a lot of other things a manager can do outside management but engineering requires too much focus.
There is a push for managers to return to engineering full time in some companies and that's reasonable if there's an imbalance but asking managers to spend 20% of their time keeping their development environment up to date (the only thing you'll get done with the amount of context switching) is immature.
not my post but i see current USA federal reserve bank rate policy will cause slow painful end to big tech companies empire building policy. the growth religion must stop hiring endless layers of managers and ‘promoting’ good engineer from individual role to manager role. line manager with direct individual contributor report sit in useless meeting all day. zero value. if they not change this..they will die in market slowly and be replaced by new generation of companies.
I also work at a faang in a senior engineering role.
I agree with what the other commenter is saying. I’ve been in several teams with several managers and xfn partners and you have a lot of different cultures. From the toxic wasteland to the ultra focused get shit done right fast environment engineers love.
To your point about why more people complain than not, it’s the human condition. Haters hate is stronger than non haters happiness and are more than willing to share their salt
I don't understand why we're still talking about SCRUM.
People saying they're using SCRUM (by this I mean "literally saying 'SCRUM'") are a dying breed and if they're not then they're cargo culting and I'm not sure why this is more of a big news than management cargo culting waterfall or kanban.
I used to be one of these process experts selling methodologies to whoever was ready to pay, from SCRUM to lean startup.
After doing this full time for 2 years the only conclusion is that none of these processes hold long enough. Why?
1/ every product / team / output is different. some teams should be ticket driven, other exploratory driven, and each of these methodologies apply to one situation only
2/ high turnover in the industry. meaning that new people come and organically change the new flavor of the day, the dynamic of the teams and the throughput of the team
3/ all of the best teams I've worked in the industry (from seed stage to FAANG through late stage startups, and even F50 companies), just do WHATEVER that works for them and don't comply with the flavor of the day (except for the looks of it). They all use a shared core set of values (deserves it's own blog post), and you can find this core set of values in most agile methodologies, buried behind ritualistic behaviors
anyway. I could go on.
Just let it go, and if you're working in one of these last companies applying SCRUM unironically, you're probably not in a high performing team. Time to move
Back in 2005, I remember working on startups running on Scrum principles. It worked well at the time, we where able to ship, grow the team, and move forward with a nice few-features-per-week cadence, working remotely, on a small team; less than 10. Tt always worked fine, but very centralized and slow, as all-things-dev were at the time.
I worked with ActiveColab in 2007, Skype 2007, Yammer 2009, Trello 2011, Pivotal Tracker 2013, Trello 2016, Confluence 2022, Slack 2013, Google Meet, and sometimes I think, scrum became _less-relevant_ over the years as more advanced product management tools became the norm and the product manager role matured by leveraging them.
These days, it's not rare to see lead developers manage kanban-like boards very effectively, releasing on time, with grace, without the need of a scrum master to coordinate efforts.
I do like asynchronous scrum daily standups using http://geekbot.com on slack, when on-site or/and distributed and doing sprints. I seen this work well on startups going from pre-seed to series B.
Personally, I am fascinated with team dynamics and how they've changed over the years. We are definitely living the best of times as a developer and I still see sparkles of well-applied scrum every now and then that works nicely.
>These days, it's not rare to see lead developers manage kanban-like boards very effectively, releasing on time, with grace, without the need of a scrum master to coordinate efforts.
Sadly, it's also common to see such kanban teams endlessly winging it and slowly losing sight of what they were trying to accomplish, at the same time burning out their teams on an endless stream of tickets and testing without ever taking time to reflect and course correct on their goals.
True. But given a team of average ability, good process (ie, good habits and conventions) can definitely mean the difference between success and failure.
I'm sorry if I'm splitting hairs a bit here, but I'd argue 'good enough' process is all you need even with average teams. Keep them focused, limit their in flight work, unblock them, iterations with feedback, etc; I just feel some people spend inordinate amounts of time trying to optimize process when process hits diminishing returns pretty quickly.
>I'd argue 'good enough' process is all you need even with average teams.
That's sort of a tautology, right? If it's 'good enough', that implies it's a good process. In my experience, Scrum is a good enough process, with very little wasted overhead. It keeps the team focused, limits their in-flight work, unblocks them and offers regular iterations with feedback.
I'd agree that over-optimization is sometimes a problem, but when something as simple as scrum fails, it's usually down to the basics, like poor meeting practices, or micromanagement, or something outside of the development process entirely, like badly underbidding the project. No amount of process will save a project that was doomed from the start due to poor budgeting of time or money.
I think 'good enough' is just an expression to mean it doesn't need to be perfect or very elaborate. Unfortunately the term scrum these days is far from precise and does not guarantee it'll be lightweight, but the principles I definitely agree with. I've seen all sorts of things, including people over-focusing on the scrum process and nitpicking about all sorts of irrelevant things. I've worked with and without scrum masters in teams as an IC and manager. I think having a scrum master is often unjustified overhead, but having an experienced SM in new teams or teams with an inexperienced manager or lacking in soft-skills, it can help fill the gaps.
And yeah you said it well at the end. There are many other things that I believe are more relevant than the process, but you do need a process teams can follow.
Honestly, this isn’t surprising. Typically external process change struggles to take root because the person isn’t there long enough to really understand the team, the problems, the culture, etc.
I don’t think this is the consultant’s fault, either. Usually the company doesn’t want to pay the money or time to do this.
Speaking as a consultant who's work does hold up, part of the job of a consultant is to make sure clients are aware of what's needed to succeed, and to turn down work that won't succeed. No matter how tempting the fee may be.
(I realize that many of my colleagues don't do this. Fie, I say. Fie!)
My statement wasn't actually directed at you—I don't know you! Sorry it sounded like a criticism.
I was responding to @scott_w saying that process change not taking root isn't the consultant's fault, because companies don't want to pay for good process change. I disagree: I think it's the consultants job to be clear about what's needed to succeed, and not work for companies that don't want to pay for good work.
Regarding methodologies, I agree that successful teams internalize the principles behind their methods and leave the by-the-book methodologies behind. I think you're being overly cynical, though. Beginners need a concrete place to start. It's like saying cookbooks are a sham because expert chefs don't need them.
I didn’t specifically apportion blame. I just said I don’t blame the consultant in the case where it doesn’t succeed due to lack of investment. Yes, you can say consultants should enforce that but many don’t. I can’t say I blame them when they need to pay the bills and there’s a paying customer.
How would you have established the core set of values otherwise? Sometimes teams click, & sometimes an egomaniac inside a team can destroy the product—and end the team. I’ve seen it.
What agile/scrum was supposed to do was kill waterfall, and provide more transparency in how a project it product was actually proceeding with demonstrations of execution or lack thereof.
you should write that blog post about that core set of values. I think a lot of people have trouble recognizing success when it's not tied to a named concept, brand, or methodology.
they do hold up for a while. but it's all ritualistic BS that is not needed. and to be clear, the teams WERE shipping. And were successful. But also quickly abandonned these methodologies in favor of some core values we implemented as a team. I don't think it's very graceful of you to assume my job was just a failure.
What I'm saying is that I was cargo culting too, because I personally believed in these methodologies.
But I realized after seeing many situations, that success is not linked to the usage of these methodologies
I believe it's pretty clear when you use these credits that it's temporary (and that it's a marketing strategy), vs claude/cursor where they have to fit their costs into the subscription price and make things opaque to you