151–160 of 522 posts
If someone is measuring productivity in code, based on the amount of lines of code written, then they have never written code. Anyone with a tiny understanding of how programming works would totally get why something so small could take so long.
Seriously, Albert? You spent 7 years and "E = mc2" is all you produced? We need to talk.
2 Stars: 2kg food
3 Stars: 3kg food
“Well KFC can do it...”
Earlier 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…
I'm still conflicted about this. On the one hand I agree. On the other, I wish we could educate people enough for them to understand Proof of Concepts and Minimum Viable Products.
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…
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 management can point out to fix. Useful managers will simply quickly point it out and move on to more important problems; useless managers will focus on it.
Do 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."
If you give a construction worker a design to build a wall, and the worker is given 2,000 bricks that must be used to build the wall, then, yes, of course the worker must lay down all 2,000 bricks to build that wall. However, if I am asked to build a computer-simulated model of said wall, and if there is a way to build the model with 200 lines of code that looks and performs identically to a model built with 2,000 lines of code, then, yes, of course I am going to build the wall with 200 lines of code.
I hope you find better pastures.
Earlier quoted context omitted.
I wouldn't say it is better, just different. Both have value. If you find a way to save millions, that might be quite worthwhile, because that might be easier than building something new that makes millions of dollars. It's all about ROI.
People shouldn’t downvote him. He’s right. i’ve done lots of small things to save time and money in the past. Management really doesn’t value it as much as making money or working on more visible projects. Telling someone that it only took me an hour to eliminate an hour of someone’s work every week doesn’t go far.
Does that help?
Earlier quoted context omitted.
> incentivizes teams to build things in small, shippable components. Isn't this a bit of a fallacy? Not everything can be broken down into chunks of work that fit into a single sprint. There's a reason I stopped bothering with Scrum a while ago, and this is high on the list.
This doesn't require that things fit into a single sprint. It just incentivizes teams to ship their work in smaller chunks. If it helps motivate a team to divide some four-sprint piece of functionality into two shippable chunks that each take two sprints, I'd call that a win. Customers get something a bit faster even if it's not single sprint-sized.
Many times I can’t tell you what tasks need to done let alone how much time is needed and break it into smaller chunks during planning phase.
If planning has to work you should be familiar with what you are building , with poor information on the bug/ code / stack planning agile is just useless overhead . it works great for yet another CRUD app where you know the requirements to the dot and know exactly how to build or fix not always , most management fail to differentiate
All the reasons in the TFA are also why it is hard to estimate , what and how much time will take .
Earlier quoted context omitted.
My first boss and my boss two positions ago both thought that way. It was incredibly frustrating. Along with: If only you programmers would stop putting in bugs we'd ship perfect software every time. (When most of the "bugs" were specification errors and not program logic errors.)
Where does program specification ends and where does program logic starts ?
Earlier quoted context omitted.
I regularly hear a friend complain about BS like this and variants. "Why did adding a button take a week, it's just a button?!" is also very popular. Not sure what's worse, that or the recurring "that element should be 1px to the left, drop everything you're working on and fix it asap"...
Try changing the colour and getting told it isn't the same shade of red as the drawings presented by the designer on his PDF presentation.
Now if there's 5 drawings with different colors, or asking "what color do you want it?" leads to a 5-week email chain...