11–20 of 126 posts
Earlier quoted context omitted.
You can measure productivity by measuring the success, but that's kinda useless for day to day software engineering management.
How do you define success? If a product bombs, is that because of the engineering or the product design?
Earlier quoted context omitted.
You can measure productivity by measuring the success, but that's kinda useless for day to day software engineering management.
I tend to go by results , and for me, "results" means shipped* code that is used and accepted by end users**, can be maintained and extended***, and doesn't generate trouble tickets. * MVP doesn't count. ** Can include users inside the organization. *** It's OK if it requires senior-level ongoing support. I think expecting it to be maintained by monkeys is a bad idea.
Earlier quoted context omitted.
I tend to go by results , and for me, "results" means shipped* code that is used and accepted by end users**, can be maintained and extended***, and doesn't generate trouble tickets. * MVP doesn't count. ** Can include users inside the organization. *** It's OK if it requires senior-level ongoing support. I think expecting it to be maintained by monkeys is a bad idea.
To me, "MVP doesn't count" feels like a crazy take -- in many roles, the _only_ ask is to produce a series of different MVP's. I guess maybe the definition of "MVP" is a bit squishy, and these people-who-ship-MVPs themselves make MVP-MVP's, which shouldn't count as shipped?
I also worked for hardware companies, where shipping stuff had some pretty serious stakes, and learned how to make sure we got it as good as possible, before getting it out the door.
I like the idea of evolutionary design, and "tuning," but I think it's a bad idea (for me) to deliberately ship bad software as an end-product.
(Also, MVP, by definition, generates lots of trouble tickets. I am allergic to trouble tickets. It's totally a personal thing, but I live by it).
There’s a weird disconnect because on the one hand I agree you can’t measure productivity and on the other hand we all know that some engineers are vastly more productive than others. So what gives?
The issue is when metrics are used to stack rank teams with no thinking put into it. You can't treat correlated metrics like direct metrics. A logger might be evaluated based on how many trees he cut down in a day. There is no comparable way to pay software engineers piecemeal.
Metrics are good, but people want to use them without thinking or taking context into consideration.
There’s a weird disconnect because on the one hand I agree you can’t measure productivity and on the other hand we all know that some engineers are vastly more productive than others. So what gives?
The most productive fpga engineer I ever hired was so hopeless with git that I had to hire a second software engineer to babysit him.
After I left both of them got fired and the product they were ahead of schedule on when I left had slipped 2 years behind before it finally got cancelled three years later.
There’s a weird disconnect because on the one hand I agree you can’t measure productivity and on the other hand we all know that some engineers are vastly more productive than others. So what gives?
"They'd beg to work for us" - what the f8ck.... if they were the best they would not beg anyone how degrading...They would be there for a mission or wanting to improve something about themseves or other parts of the world.
There's nothing here apart from Agile coach wanting to get some more work.
1984 was released in 1949, if anyone thinks these words / values really mean what is writen wow. People, Internal Quality, Lovability, Visibility, Agility, Profitability...
What an amazing article on "de-FAANGing" the perverse org/incentive structure of most startup/tech places. Would love to see more of this type of leadership in the real world.
"We’re an inverted organization. That means that tactical decisions are made by the people who are doing the work, not managers. (In theory, anyway, we’re not perfect.) So we’re looking for people who have peer leadership skills, who are great at teamwork, who will take ownership and make decisions on their own."
+1 for Extreme Programming. I've been a fan from the beginning when Agile was all the rage and my recommendations for XP were met with blank stares.
There’s a weird disconnect because on the one hand I agree you can’t measure productivity and on the other hand we all know that some engineers are vastly more productive than others. So what gives?
You can measure productivity with correlated metrics. The issue has always been that the metrics which are easy to track don't line up incentives with the actual business goals. A group of 10 people who write 200k loc per year are probably more productive than a group of 10 people who write 10k loc per year. If you took those metrics and then did an investigation of the people in your company writing 10k loc you migh…