A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…
I seem to remember Joel Spolsky recommending that UI demos be done on paper... with pencil. That way even a manager can see what it will look like without thinking that it's all done. (Can't find a reference quickly.)
You've only added two lines – why did that take two days?
161–170 of 522 posts
Re: You've only added two lines – why did that take two days?
#162Earlier quoted context omitted.
Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…
Also, never use the word "done" in any context in a meeting like that. Do not even say: "I'm not done". They won't hear the "not". Say, "Development is still in progress" or something similar. I got chewed out for something being released (where it was found to be broken) to a customer because I said something like: "I'm about 80% done with testing, but I haven't run into any issues yet." They released it even though…
Did you really get chewed out? That seems pretty much like a deal breaker for me. Managers are collaborators, not parents, and have no place talking to co-workers in such a diminutive manner.
Re: You've only added two lines – why did that take two days?
#163A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…
> look at a UI prototype and consider that 90% of the solution Management tip: Make the UI reflect the actual state of the project. The UI should be UGGGLY and should get prettier as the backend work gets finished. If if the artists prettify it; make the animations and interactions janky and sluggish. Never make the UI better than the actual implementation. Bonus tip: Always have something slightly off in the UI that…
Re: You've only added two lines – why did that take two days?
#164Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.
They don't always make the comment out loud, but you can tell they're thinking it. They absolutely use lines of code metric at my company. I don't miss any chance to tell my manager it's complete bullshit. His answer: "Engineers are supposed to write code, just like construction workers are supposed to build houses."
Oof, that's a false equivalence. Construction workers have blueprints for how things are supposed to be built. You're (generally) making the blueprint as you go along, based on vague specifications in many cases. This can depend a lot on how your organization designs software, of course.
Re: You've only added two lines – why did that take two days?
#165Earlier quoted context omitted.
Why would it be? For all the things that can be atomic like that, it's good practice. The bigger ones just take time, and aren't shown, until ready for use.
It's an anti-pattern to simply not demo any progress until done. If you're doing agile right (loaded statement), the solution is to make sure everyone understands what's being done. If the audience is expecting all demos to show complete products, find a different audience to demo done-but-incomplete work. The idea is to get feedback before you've sunk six months into something that may not meet expectations.
That isn't what I got out of the comment.
Progress gets quantized. Some quanta are small, easily shown, etc... other quanta are a bit bigger, less easily shown.
There is a similar problem in manufacturing.
Atomic releases.
While making something, there are many subtle tweaks to the BOM. Changes, substitutions, removals, adds.
Upstream people can make a real mess out of all that, and one way to prevent it is to only deliver releases that are resolved and intended for manufacture.
"where is revision 4?"
Doesn't exist, won't get manufactured, etc... "Use Revision 5 plz."
For the case of insuring expectations get aligned, a mock up can be used. Deliberately used to generate a spec.
Re: You've only added two lines – why did that take two days?
#166Those two lines took two minutes to write.
Knowing which lines to add, and where, took 25 years of experience.
That's what you are paying.
Re: You've only added two lines – why did that take two days?
#167Oh, that reminded me of my "two lines" moment. Years ago I was writing software for some university project, and one feature took me a few days to figure out and implement, and when I checked the diff I realized that "all" it took was removing some 20 lines of code. I literally added a feature by removing some constraints that I had previously introduced.
Deleting code is giving your future self a gift of not having to maintain that code anymore.
Re: You've only added two lines – why did that take two days?
#168Oh, that reminded me of my "two lines" moment. Years ago I was writing software for some university project, and one feature took me a few days to figure out and implement, and when I checked the diff I realized that "all" it took was removing some 20 lines of code. I literally added a feature by removing some constraints that I had previously introduced.
Deleting code is giving your future self a gift of not having to maintain that code anymore.
Yes, I like to say it as "A line of code deleted is a line of code debugged."
Re: You've only added two lines – why did that take two days?
#169Earlier quoted context omitted.
I know someone that worked at some skeezy company in Menlo Park that got passed up for a raise after spending months navigating the bureaucracy to save the company millions on their operating costs because they didn't write enough code. This was in the last four years. Edit: And they quit right afterwards.
The defense I've seen is that it works reasonably well as a measure of productivity _if_ you're working in a similar team and in a stable codebase. From what I understand a lot of product teams at FB have nearly frictionless development tooling for their use cases so the pressure is to produce volume.
Was the team that caused the outage of half the apps on iOS one of them?
Re: You've only added two lines – why did that take two days?
#170This article made a number of great points.
> I know some developers don't like having to fix bugs, and so do whatever they can to get out of it. Claiming there isn't enough is a great way to look like you're trying to help but not have to do anything.
God, this behavior has annoyed me so much at times. I've worked with a few developers that were not bad overall, but would use the slightest excuse to punt on fixing an issue they were tasked with but didn't want to track down. Regularly weaseling out of tasks like this wastes the time of multiple people and either ends up back with the original dev or gets dumped on a more responsible worker.
> Because I took the time to verify if there were other parts of the code that might be affected in similar ways.
Not looking for other places in the code that are very likely to be affected by the same issue is bafflingly common, in my experience. Although I would say that managers are much more often to blame for this behavior than the devs. Any workplace that puts less weight on fixing an issue well than on artificial metrics like number of tickets closed is incentivizing exactly this type of behavior. Why bother getting criticized for spending all day fixing a simple bug the right way when you can fix 5 different iterations of that same bug and close 5 tickets in the same amount of time?