201–210 of 222 posts
Earlier quoted context omitted.
confirmation bias indeed works that way more often than not: it confirms what you already believe
If you declare by fiat that every confirmation is confirmation bias, you've made knowledge impossible.
Counting lines of code as a production metric is very stupid. I remember solving an unsolvable 20 years old bug with a line of code, another 3 years old with a order by. How to measure the impact of a line of code? And in my experience, bad programmers write a lot more code... I will never forget the story[1] of a Microsoft developer rewriting a piece of IBM code that had 33 thousand characters, after rewrite ... 220…
Using production metrics as a whole is very stupid and a good way to get devs to optimize for the metrics rather than quality work. A contemporary example would be a company that promotes for "impact" (i.e. launching new products) which is a great way to have a bunch of failed products that nobody maintains!
For example, if quality is your goal, then the metric you give your devs is "number and severity of bug reports coming in from customers". If unsatisfied feature requests are part of that number, then the devs have to strike a balance between churning out features and preventing bugs (and fixing discovered ones).
Obviously your customer support needs a different metric.
Earlier quoted context omitted.
What specific needs are met by daily status updates? Professionals outside of software don't do that. The best software projects don't do that. It's very popular in CRUD projects led by non-technical middle management with trust issues.
> What specific needs are met by daily status updates? You are assuming (1) that standups are status updates, and (2) that they are scheduled by manager, and (3) for benefit of the manager. In the last several teams I’ve managed, it’s the crew that has encouraged meeting daily, and in the standups they are mainly talking to each other. It’s where they cover hot topics and bugs for the day quickly, with the fluidity o…
Earlier quoted context omitted.
What specific needs are met by daily status updates? Professionals outside of software don't do that. The best software projects don't do that. It's very popular in CRUD projects led by non-technical middle management with trust issues.
> Professionals outside of software don't do that. What, and I mean this in the nicest way possible, the everliving fuck are you talking about? Professionals do this constantly. Go sit in an ER and watch the hand off between shifts. Go see any serious manufacturing facility and see them review daily everything that happened the previous day. Go see an effective sales org in action. The scrumbags may have ruined softw…
Why are there no laymen agile coaches at law firms, and no "today I did this, today I did that" breakfast meetings in finance, or in CS academia? Other professionals don't accept this kind of infantilization.
Earlier quoted context omitted.
> What specific needs are met by daily status updates? You are assuming (1) that standups are status updates, and (2) that they are scheduled by manager, and (3) for benefit of the manager. In the last several teams I’ve managed, it’s the crew that has encouraged meeting daily, and in the standups they are mainly talking to each other. It’s where they cover hot topics and bugs for the day quickly, with the fluidity o…
They just recommended cross-checking status updates in "stand up" meetings with commit history to catch engineers underperforming. That is (1) (2) and (3).
If you ever move to management, you'll see that as lovely as it would be if every hands-on developer was an amazing and super-productive engineer writing high-quality code and delivering tons of value , the reality is that most teams have one or more people that are struggling and aren't getting much done, but aren't forthcoming about it. They'll represent their work as very challenging (which it is, to them), meanwhile others on the team are objectively better and faster at figuring out solutions and not getting stuck, and they understand the codebase better, and the architecture, and so on. The manager has a duty to spot when this is happening, and engage with the engineer immediately to figure out what's going on and try to help them.
Engineer managers should themselves be strong engineers (and in every company I've worked at, this has been the case up the senior leadership chain), so that they can form a realistic, fair, and reasonable assessment of whether there's a discrepancy between how an engineer represents their work, versus what is shown in the actual commit history.
Earlier quoted context omitted.
They just recommended cross-checking status updates in "stand up" meetings with commit history to catch engineers underperforming. That is (1) (2) and (3).
A manager has a duty to "catch" (as you put it) underperformers, to help them improve. If you ever move to management, you'll see that as lovely as it would be if every hands-on developer was an amazing and super-productive engineer writing high-quality code and delivering tons of value , the reality is that most teams have one or more people that are struggling and aren't getting much done, but aren't forthcoming ab…
Earlier quoted context omitted.
> The old days of a software as an artisanal craft is long over imho. In corporate or government software work, sure. But there are no guilds anywhere in those organizations... unless you count the upper executives. You might not get paid for it, but the artisanal craft of software is alive and well in free and open source software around the world. Tons of those projects get posted to HN. An app can be a home cooked…
> free and open source software around the world. aka, you are not economically valued, and in order to be artisanal, you have to sacrifice monetary gains to achieve it. > if it is your startup, you can write code however you want. yes that is true, but a startup is much more than just code. it's a business - with all of the extra work that entails.
Gave myself RSI deleting On the plus side I replaced an O(n²) algorithm with a faster one in the very next commit. Needed to get rid of the ninety copies of the same bad idiom first.
I was giving myself RSI by deleting what was happening) and Can feel you right there.
Begrudgingly I hope...
If you replaced 4000LoC with a regex that regex scares me...
Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…
oh no. you're responsible for a group of skilled and not so skilled engineers in a domain that you don't understand. all is not lost. what is your only goal - to maximize your teams contribution to the goals of the company. full stop. its not to stack rank your employees unless it serves that greater goal. but you don't understand the domain. oh no. all you can do is develop a human relationship with the team. listen…
You should consider working somewhere where management is deeply technical. At everywhere I've worked, the entire eng-management chain (up to CEO) fully understood the domain (as you put it), the state of the art, the key system architectures, and so on. The idea that an eng manager's role should be limited to "developing human relationships and being attentive", would simply not fly.
Eng managers need to be able to go into code, and they must be able to gauge the complexity of the work under them, or they'll be unable to spot the difference between someone aggressively chasing a nasty heisenbug for weeks, versus someone struggling for weeks to put together a basic block of working code.
It was a great write up in its time but has since become a goto cliche for people who can't write much code.
Article: "Did you know that geniuses like Einstein tend to be night owls?" Unemployed guy who wakes up at 11 a.m. every day: "I must be a genius!" Barba non facit philosophum: a beard doesn't make one a philosopher.
― Carl Sagan