[HN Gopher] You've only added two lines - why did that take two ...
___________________________________________________________________
You've only added two lines - why did that take two days?
Author : gregdoesit
Score : 254 points
Date : 2020-07-14 18:38 UTC (4 hours ago)
(HTM) web link (www.mrlacey.com)
(TXT) w3m dump (www.mrlacey.com)
| dev_tty01 wrote:
| -2000 lines of code.
| https://www.folklore.org/StoryView.py?project=Macintosh&stor...
| ilyas121 wrote:
| One time I spent 3-4 months working on a project that amounted to
| adding 11 lines of code to a config file on kubernetes. Tbh, a
| lot of it was bad communication, but it was also because I wrote
| and rewrote so much of the same code.
| not2b wrote:
| I recall a story about someone at a government contractor who did
| a major refactoring and removed thousands of lines of code from a
| project, increasing its performance, only to be told by
| management that they'd signed a contract that said the company
| got paid by lines of code delivered, and his improvement would
| cost them tens of thousands of dollars, so revert the whole
| thing.
| pintxo wrote:
| As long as we are counting LOC before compiling, that can be
| solved easily: if (false) { /*
| original code stays here, as we are payed by LOC */ }
| else { /* write your new code here */ }
| flingo wrote:
| As long as this is contained to the metrics-metagame branch
| of the git repo, I am fine with this.
|
| Get 80k commits in, before lunch.
| ZoomZoomZoom wrote:
| Realistically, it would take some compile time conditionals
| in a bunch of places to get rid of the dependencies. The best
| part, you'll get paid for all those #ifdefs, whens and
| #[cfg()]s! You can even split longer functions to be able to
| wrap each one of them in those conditionals! Where do I sign
| up?
| vikramkr wrote:
| That's a pretty bad breakdown in communication- the manager
| should have communicated how the contractor was paid and the
| programmer should have spent their time working in line with
| that - whichever end that breakdown happened on that sounds
| like that led to an awful lot of misery and wasted time - ouch
| mrwh wrote:
| "Because the text was so light it was difficult to read"
|
| Snark aside, it's quite a good list.
| ChicagoDave wrote:
| I can't like this post enough. We are not accountable by lines of
| code. Delivering healthy, maintainable software requires thought,
| experience, and thorough testing. This is why companies have
| taken so long accepting the idea of unit testing.
| adrianmonk wrote:
| You've only rendered one two-word verdict -- why did that take
| five days of deliberation? You had twelve people working on it!
| [deleted]
| dllthomas wrote:
| One of my favorite contributions involved two commits: one that
| added 5 lines, another a bit later that removed a different 5
| lines. This was after more than a week of building tiny models to
| understand how the system might behave. Thankfully I was on a
| team that appreciated it, although the reduced load on on-call
| quickly drove the point home :)
| augustk wrote:
| With unit tests included it would probably be more than two
| lines.
| tdrp wrote:
| We had a non-tech lead at some point (although his title was
| something like development manager) and he would praise my
| coworker for how many check-ins he did. Except that coworker
| would do things like:
|
| 1- Copy-paste an entire class into a new class and change a
| single constant in it, because he was too lazy to do inheritance.
|
| 2- "Solve" multiple bugs a day that he had introduced himself the
| day before.
|
| 3- Loudly complain about other people's frameworks/codes.
|
| He was the super confident type even though he was wrong more
| often than not. But paired with a non-tech lead with his own
| impostor syndrome, it was a recipe for disaster.
| throwaway_dcnt wrote:
| That word (imposter syndrome) does not mean what you think it
| does :)
| arnvald wrote:
| Oh, 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.
| zdw wrote:
| Deleting code is giving your future self a gift of not having
| to maintain that code anymore.
| Scramblejams wrote:
| Yes, I like to say it as "A line of code deleted is a line of
| code debugged."
| rmason wrote:
| Because I had to explore all the things that wouldn't work before
| finding the two lines that did.
| newshorts wrote:
| This summarizes the argument pretty well and should suffice as
| a tl;dr.
| not2b wrote:
| Too bad about the low-contrast gray on white text. It is a source
| of eyestrain.
| yongjik wrote:
| Came here to say this. Gray on white for anything other than
| disabled options is a sin. This website is particularly
| egregious.
| tempodox wrote:
| Agreed, came here to say the same:
|
| https://contrastrebellion.com
| whoisjuan wrote:
| 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.
| mv4 wrote:
| Seriously, Albert? You spent 7 years and "E = mc2" is all you
| produced? We need to talk.
| quickthrower2 wrote:
| Michelin Star: 1kg food
|
| 2 Stars: 2kg food
|
| 3 Stars: 3kg food
|
| "Well KFC can do it..."
| joe_the_user wrote:
| I know the reasons for not producing code consistently. They're
| logical and I can even verify them. BUT I am still frustrated
| with _myself_ when I don 't produce significant code each day.
| slaymaker1907 wrote:
| I'd rather write 2000 lines in two days since if I've only
| written 2 lines, figuring out those 2 lines must have been
| miserable.
| arendtio wrote:
| Actually this is one of the upsides of web development: Since
| every line contributes to the file size of your software and
| therefore to the loading time there is a motivation for keeping
| the code base small.
|
| Sadly, there are many projects out there which obviously failed
| to reach this target at some point.
| aequitas wrote:
| This can also go suprisingly wrong when management decides code
| size is the performance metric needed to improve the site and
| hires a "performance engineer" who abolishes all structure and
| abstraction in the code, making it near-impossible to debug and
| maintain. But at least it runs fast.
| arendtio wrote:
| True, the quest to reach a small file size can also lead to
| various down-sides. Cryptic architectures and weird code are
| just two popular symptoms.
| glouwbug wrote:
| What if a single line change, given it took 2 weeks, fixed 40% of
| your crash rates? That fix alone is worth millions, almost 100x -
| 1000x the engineer's hourly salary in down time.
| arendtio wrote:
| A manager would certainly argue the other way around: The
| person who created the bug costs the company a lot of money.
| Fixing that single line was just necessary because someone
| didn't do his work in the first place. So fixing that line is
| something you should do off-the-clock.
|
| This is just one of the reasons why I appreciate it when
| managers have at least some coding experience.
| cgrealy wrote:
| To that manager: that bug wasn't the creation of a single
| developer. It went through code review. It had unit tests. A
| QA verified its initial implementation and a Product Owner
| signed off on the feature as done.
|
| If it wasn't caught before prod, it's either such an edge
| case as to be almost impossible to catch OR (more likely)
| it's representative of a systemic failure within the
| organisation.
| BurningFrog wrote:
| Conclusions:
|
| 1. Picking a good manager is very important!
|
| 2. Communicating with your manager is very important!
| Lammy wrote:
| 1. Being in a position where you have the privilege of being
| able to pick a good manager is important :)
| williamdclt wrote:
| I remember hearing somewhere that the reason n.1 people leave
| their job was their manager. Don't know if that's true but
| the idea's there. So it makes sense that your manager should
| be a major decision criteria when you pick a job (being able
| to actually pick a job is also a privilege, but it's fairly
| common in SWE)
| Lammy wrote:
| Many companies have a team-selection process that starts
| after (and is separate from) the actual hiring, e.g. you
| might not know who the available managers are or if there
| even are any 'good' ones.
| otikik wrote:
| Those 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.
| RandomInteger4 wrote:
| Because I procrastinated due to the overwhelming complexity
| overloading my mind with the myriad scenarios resulting from
| those two necessary lines and my lack of experience with this
| scenario depriving me of the intuition necessary to prune the
| aforementioned tree of mental complexity in an efficient manner.
| Piskvorrr wrote:
| Because I have spent time thinking, not merely typing. (The
| error "programmers are just overpaid typists" is widespread)
| Jtsummers wrote:
| 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.)
| neatze wrote:
| Where does program specification ends and where does
| program logic starts ?
| [deleted]
| beckingz wrote:
| Where management says it does.
| Jtsummers wrote:
| Program logic error: // return the
| maximum value from an array return array.min();
|
| Specification error: Only users with role
| X can access this content. [where X should've been
| Y]
|
| In the former case, a test should catch it (because the
| code isn't doing what we believe, per spec, it should be
| doing). In the latter case, only validation (confirming
| with customers) can catch it. Any test that is run
| against the code will be based on the spec which tells us
| to do the wrong thing.
|
| Though we usually didn't run into the latter case, ours
| were mostly embedded systems. So the problem was more
| like: You implemented this against Industry Standard
| 1234-A, but we're implementing against Industry Standard
| 1234-B which says that message Foo word 15 now has a
| range of 1-20, not 1-19, and 20 means "cease operations",
| and 18 has been changed from "cease operations" to "halt
| and catch fire".
|
| So one system was developed per one spec, and another per
| a slightly different spec. The other common scenario was
| that the specs weren't created from thin air, but rather
| based on a preexisting system. And the authors of the
| spec misinterpreted what the preexisting system did and
| gave an incorrect specification for a behavior. When
| testing against the old system (or with the old system as
| these were mostly communication systems) you'd see a
| difference in behavior or failure to communicate. But
| since tests were never truly comprehensive, many of these
| errors could make it out into the world.
| neatze wrote:
| What happens in case where specification is:
|
| [User inputs X1, system displays Y]
|
| On system crash user input was X2.
|
| Is this specification or program logic error ?
| ak39 wrote:
| Because coding is like the art and science of distillation.
| Cheers.
| staycoolboy wrote:
| TL;DR: Regression.
|
| This is one place where I learned a LOT from Intel. They differ
| significantly from every other company I've worked for: they knew
| from 30+ years of experience that validation and regression are
| 90% of the man-years of effort. For each CPU there's 1 lead
| architect, about 5-10 "lords" who scheme to become lead architect
| (it's like the fucking Tudors over there), ~30 microarchitects
| who write the RTL/VHDL, then about 80 designers, and finally
| 300~400 validation engineers who verify the circuits drawn by the
| designers match the RTL written by the microarchitects, and
| validation takes multiple quarters for each rev, although metal
| layers are slightly easier.
|
| Every other company since then is just like "You're a contractor,
| you should be faster than new college grads... chop chop."
|
| I have contract with a cloud enabling service that deploys to
| vendors who make surveillance devices. Every time I touch a
| critical piece of code, even if it is a single line of code, I
| have to validate on their 10 gateway platform SKUs and 30 level-1
| device SKUs (and another 40 level-2 and below): That's at least
| 300 combinations (I only have 30 set up at a time, and have to
| change 10 times to swap in new hubs); then I have to run 60-90m
| of regression tests. It takes two or three days to finish any
| regression, assuming there are no bugs. I could cut that down to
| a day if I had more lab space, but if anything goes wrong: BAM!
| That's at least two weeks to debug and file new issues and
| regress.
|
| Can't say it enough: regress from day one. Hardware gets this a
| bit better than software, because mistakes cost billions, but
| real software should start from a test-forward posture: e.g.
| write tests first, then write code to pass them.
| addicted44 wrote:
| If the reporter hasn't provided enough information to recreate
| the issue (it's obviously not a major deal breaking issue
| otherwise it would be obvious and easy to recreate) and they are
| internal to the company, tell them to provide more information
| before moving forward.
|
| The author's approach is good for external bug reports, but they
| don't clarify that's indeed the case here.
|
| I have to strongly appreciate the author for finding the root
| cause and tackling that instead of the symptom.
|
| So often, especially in front end coding, you will see an
| exception being thrown because of a null value being passed in,
| and the "fix" checked in by the developer basically returns the
| default value if null is passed in, when they should be
| investigating and fixing why a null was passed into the function
| in the first place.
|
| If your function has a contract that forbids nulls from You
| resolve the immediate bug, but this almost certainly leads to
| multiple bugs being created in the future (or worse, something
| that is quietly wrong, because 1 row in a 100 row table is
| missing and no one noticed) until the root issue is resolved.
| CodeWriter23 wrote:
| Dude, you could have just said "because I take my job seriously
| and executed with complete diligence".
| rubyn00bie wrote:
| Oh this reminds me of what went from one of the most infuriating
| questions I would get asked by investors to one where I almost
| wanted to bait them into asking it...
|
| "Why/how is this worth X dollars/time? I know someone who says
| they can do it in a week." To which, I eventually learned to
| reply: "Wow, well... In that case, let me shoot you an article on
| how to build a Twitter clone in 15 minutes. [awkward pause while
| I smile at them] There's a lot more than just literal lines of
| code that goes into building a successful software product."
| dboreham wrote:
| Gaslighting occurs in the workplace too.
| quickthrower2 wrote:
| Nice comeback
| graton wrote:
| A good commit message can also help to explain why the two lines
| of code took so long.
| zabzonk wrote:
| Nobody should manage programmers who is not themselves a very
| experienced programmer. Otherwise, you are in Dilbert Country.
| msclrhd wrote:
| The tricky part of this is that not all programmers make good
| managers, or want to be promoted into management. They are
| different skill sets. That said, having a basic understanding
| of the difficulties and things that take time (learning new
| technology, investigating/debugging an issue, etc.) would be a
| good thing to have as a manager. Also, being able to assist
| where possible -- asking if the developer needs someone to help
| out, finding people with the relevant skills to mentor the
| developer (or finding suitable courses/training/books), etc.
| twodave wrote:
| I mean, is it really this hard? This is not a good/bad
| manager problem to me, this is an organizational culture kind
| of problem. As a manager I'd expect my three top priorities
| to be ensuring enough devs are on the team, communicating
| priorities effectively, and unblocking the devs on the team
| as needed.
| shoes_for_thee wrote:
| It's beside the point, but grey-on-white fonts give me a
| headache.
| rurp wrote:
| This 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?
| kentlyons wrote:
| One of my favorite personal commits was removing about 5000 lines
| of dead code tightly woven into many other parts of the overall
| codebase.
| celticninja wrote:
| The fix is a refactor of a refactor of a refactor of the actual
| fix.
| m3kw9 wrote:
| Cuz trying to understand someone's code, testing, debugging and
| finally apply the fix, and test again.
| kevsim wrote:
| 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.
| beefield wrote:
| > Do people actually have fights like this with management at
| their companies?
|
| There was a time when I thought this video was funny:
|
| https://www.youtube.com/watch?v=BKorP55Aqvg
| pintxo wrote:
| Still think it's funny. But yes, it's no fun while you are
| the expert.
| cortesoft wrote:
| A lot of software development still happens at businesses that
| are not 'software companies'. The experience is very different,
| with a much different culture around software.
| RandomInteger4 wrote:
| This scenario seems like something that's more common in
| freelance work where the client has access to the code for
| whatever reason.
| decebalus1 wrote:
| You'd be surprised...
| birdyrooster wrote:
| 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.
| 0xEFF wrote:
| It's better to find ways to make more money than to save it.
| There's a floor but no ceiling in much of what we do.
| rriepe wrote:
| Thanks. This comment blew my mind. This perspective is so
| far on the other side of things that I never considered it.
| stormdennis wrote:
| It feels like saving money might also be more
| environmentally friendly than growth.
| BurningFrog wrote:
| If your revenue can grow exponentially, that's probably the
| right priority.
|
| Most companies aren't like that though. Know your company!
|
| Also consider if you can run out of money before growth
| kicks in...
| mring33621 wrote:
| Yessir, Mr. Belson!
| [deleted]
| tehjoker wrote:
| The ceiling is the size of the addressable market.
| jedberg wrote:
| 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.
| melling wrote:
| 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.
| VLM wrote:
| Someone was building an empire by having employees do
| manual data entry instead of parsing json files. All the
| way up the mgmt tree there are fewer direct reports.
| Nobody ever gets a job title promotion by having fewer
| direct reports.
|
| Even worse, someone else now has to explain "why they did
| it wrong to begin with" regardless if the replacement
| technology existed or not at the time of original process
| creation.
| jacobr1 wrote:
| A lot of this just visibility and internal salesmanship.
| Having an engineer standup at an all-hands and be lauded
| for saving $X million right after the sale-gal is lauded
| for closing the deal with $BIG_CO is something I've seen
| done, and it does it get recognized.
| jedberg wrote:
| That's just bad management, not an axiom.
| fphhotchips wrote:
| This heavily depends on the industry you're in. In
| software, yes this may be true, but in low margin
| industries it's absolutely not.
|
| The maths is simple. If my margin is 1%, and you make me an
| extra $100, I keep a buck. If you _save_ me $100, I keep
| that whole $100. If I 'm smart, I can use that to drive my
| prices down, and take more market share without reducing my
| margin.
|
| Obviously it becomes less clear if your margin is >20% or
| so.
| buran77 wrote:
| Making a million or saving a million are equally important
| in the end assuming one of them doesn't require
| particularly unreasonable ways. Sometimes it happens that
| the floor is really close to the ceiling and lowering the
| floor is the easier thing to do. Go for the low hanging
| fruit first. If you have too much useless clutter it makes
| sense to remove it rather than break down walls to expand.
| grecy wrote:
| Certainly many companies prefer this approach because so
| many goals are tied to increasing revenue, and certainly
| personal bonuses are too. Very few people get rewarded for
| decreasing costs. In my last (big!) company it was never
| even talked about. Increase revenue was the only goal.
|
| Also making more money is better, because it means growing
| the company with more employees and more job safety for
| everyone.
| akhilcacharya wrote:
| 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.
| ramraj07 wrote:
| Was the team that caused the outage of half the apps on iOS
| one of them?
| cek wrote:
| I'm a maintainer of an OSS project with other contributors. I
| have fights like this all the time because others are
| constantly just wanting to fix the symptoms. This is for a
| project that is a framework/API, where the saying "the best
| programmers remove more code than they add" should be even more
| true.
| archi42 wrote:
| 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"...
| seamyb88 wrote:
| I sometimes battles with myself over things like this. I code
| for my job and for recreation, the latter being where UI
| comes in. In order to get anything done in recreational
| programming you have to concede that you're not building an
| app with bells and whistles. Yet I lose so much time over
| $hit that does not matter. Usually aesthetics.
| touristtam wrote:
| 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.
| detaro wrote:
| I mean, that's totally reasonable if that's the spec (not
| to mention hopefully trivial to fix).
|
| Now if there's 5 drawings with different colors, or asking
| "what color do you want it?" leads to a 5-week email
| chain...
| silveroriole wrote:
| A funny side-effect of this that I ran into: customers who
| went to tortuous lengths to avoid requesting a new page or
| button, because they'd had that past experience of 'just a
| button' taking 2 weeks. They still wanted all the new
| functionality, but glued onto the existing pages/buttons
| because they thought it would save time! An interesting
| misunderstanding :)
| ajford wrote:
| Not everyone has good managers.
|
| $JOB-2, admittedly about 4 years ago now, the good manager with
| a background in software left for a better opportunity and was
| replaced by someone who's background was management. With no
| insight into the subject matter, they fell back on whatever
| they thought they could quantize.
|
| Got numerous things like that, though my team lead and our
| project manager did a great job of shielding the team from that
| crap, we still occasionally hear it come up in group meetings
| and the like.
|
| I even got a task handed directly to me, bypassing everyone
| above me, to "estimate how much it would cost to migrate all
| those linus apps your team has to windows. They'll run better
| there". Just the windows licenses alone would have cost us
| about half the existing server costs since we were using AWS
| instances. Also included a line item that included recruitment
| costs for a new developer, and verbally informed him that it
| would likely involve hiring a new team, as the existing team
| was hired specifically as linux developers.
| trav4225 wrote:
| One would wish. Personally, I don't think I've ever worked
| under a manager who understood software development. It tends
| to be all about what they can see (GUI) or about nearly
| meaningless metrics on a dashboard (LOC, tickets closed, etc.).
| Again, just in my personal, limited experience.
| dgb23 wrote:
| The problem is not "manager/client doesn't understand
| software development". That's fine.
|
| The problem is lack of trust in you as the expert and
| possibly a lack of self-awareness (they think they
| understand).
|
| A manager/client should make mostly strategical decisions
| like: We should solve this problem, here are the resources.
| And almost never tactical.
|
| They also shouldn't even care or look at LoC. They shouldn't
| be worried about metrics of 'effort' at all.
| trav4225 wrote:
| Ah, agreed. I guess that, in my experience, not
| understanding SW development tends to go hand-in-hand with
| not trusting the developer.
|
| I found your phrase "lack of trust in you as the expert" a
| little jarring because (again, in my personal experience)
| considering the developer to be a domain expert is somewhat
| of a foreign concept. I suspect/hope the situation is
| better elsewhere in the industry. :-)
| dgb23 wrote:
| I meant 'expert' as in the person responsible for the
| technical side. Not in the sense of 'they know everything
| they need to know all the time' or anything like that.
|
| > I suspect/hope the situation is better elsewhere in the
| industry. :-)
|
| I do freelance, client work. Alone and in (very?) small
| teams. Typically my/our clients only have a superficial
| understanding of everything technical (if at all). Trust
| often needs to be earned.
|
| One way to gain trust is being creative/optimistic and
| explaining feasible possibilities and strategies. Another
| one is being pragmatic and not selling them something
| they don't need, or might not need.
|
| And then the most important one is to have conversations
| about their problems and wishes. Showing that you
| understand them by asking questions and writing a
| specification. And explaining your (iterative) workflow:
| "Let's figure this part out after we've done this other
| part." I guess this is the "domain" part of the process.
|
| My experience is that if trust is in danger then the work
| is less valuable, less fun and less sustainable.
| Indications of this are things like we discussed before
| and similar:
|
| - Trying to measure effort instead of rewarding value.
|
| - Nitpicking, bikeshedding and other distractions.
|
| - Overstepping their expertise (typical for UI design, a
| bit less for programming)
|
| Now most of my interactions are good but sometimes I get
| the above. We're actually discussing of doing more
| upfront communication work in the offers and initial
| discussions to prevent these things (even by filtering
| out clients/collaborators) and to set a tone. Because
| again, this is unsustainable on multiple levels and it
| never ends well...
| seneca wrote:
| You would hope so, but I've seen an Engineering Director at an
| otherwise well run software company use number of Github
| commits as the central reason to put someone on a performance
| improvement plan as recently as 2019. Granted, this was someone
| who was a professional manager and hadn't been an engineer for
| the last 90% of their career, and many people were shocked by
| it, but it happened.
| kevsim wrote:
| I was wincing a bit when I made my initial comment fearing I
| might actually be wrong. This hurts to read.
| majormajor wrote:
| Were they right about the person being a low performer?
|
| I'm curious if this is "everybody knows this person isn't
| doing any work, here's a blindingly obvious metric to use to
| defend this move to HR" because HR orgs often hate things
| that don't have metrics attached, or if it's "I don't
| understand what this person is doing, and I don't see any
| commits, so it must be nothing"?
| seneca wrote:
| Completely valid question, and I think you make a great
| point here. A lot of baffling managerial behavior is
| because the manager is working in a baffling bureaucracy.
| Unfortunately, I think this situation was largely of the
| latter case, and maybe some motivations I'm not aware of.
|
| They were a senior engineer that spent a lot of time
| coaching the rest of the team, and less time on their own
| personal work. The commits data point, in my opinion,
| should have been the beginning of a conversation that ended
| with the manager asking this person to adjust their
| priorities. Instead it was presented as an accusation that
| the person wasn't getting their work done, which ultimately
| lead to them feeling insulted and quitting.
| samatman wrote:
| Which leads me to want to fill the rest of the story in:
| the manager of the senior engineer had a friend he wanted
| to promote, and this was the expedient way of getting the
| obstacle out of the way.
|
| That could be completely wrong, of course. But would it
| surprise you?
| majormajor wrote:
| I agree with you on what a manager who doesn't know what
| they're looking at should do there. You gotta dig in and
| find out![0]
|
| I've been fortunate recently to not work in orgs where
| mentoring and collaborating like that is looked down upon
| - instead, it's encouraged - but my ongoing struggle is
| to figure out how to quantify it.
|
| I've got two similar but distinct motivations for wanting
| to quantify it:
|
| * If I have a manager who looks less favorably on it, I
| want to be able to demonstrate my worth; but also,
|
| * If I'm spending most of my time trying to mentor the
| rest of the team, I want to see how well I'm doing - and
| I want to be able to change things and see if it results
| in positive or negative changes
|
| Sadly I've completely failed at coming up with how to
| quantify this so far. It all comes down to qualitative
| peer feedback/manager feedback...
|
| [0] As a technical person, I try to practice the reverse
| of this: if someone asks for a feature or claims there's
| a bug, I try to dig until I fully understand why they're
| asking for what they're asking. So I think asking for
| similar curiosity and depth from a non-technical person
| is fair.
| seneca wrote:
| Well, just spit balling, but you should see it in team
| velocity. The effort you're spending coaching should show
| up in the output of your team members.
|
| Assuming there's some kind of constant ongoing engagement
| with one person or group, I'd expect an immediate dip in
| velocity as your productivity goes elsewhere, then it
| growing, and maybe evening out to before-engagement
| numbers (approximately), as they reap the benefits of
| learning from a senior engineer. Then, as you're able to
| return to normal duties and they're able to apply the
| lessons, you should see velocity greater than before the
| engagement. That delta should be somewhat quantifiable
| and, ignoring other variables, should represent the
| benefits of coaching.
|
| There's also huge value in the increased job satisfaction
| for both mentor who enjoys mentoring, and a mentee who is
| learning. That should show up in any kind of employee
| satisfaction survey, or retention numbers.
| mateo411 wrote:
| I think it's fair to use this as supporting evidence. If they
| are assigned tasks that aren't too difficult and they aren't
| completing them really fast, and there is a PR process in
| which changes are landed into the repo, then I think it's
| fair to use the number of commits to the repo.
|
| If anybody can push commits to the repo, then it's a useful
| metric. Finally, this sort of action should be take after the
| manager has worked with their report, by having somebody else
| help them, or put them on a different project.
| [deleted]
| alexbanks wrote:
| Yes. The industry moves at a snail's pace, and is very
| different from what you'd read on HN. A huge % of dev jobs are
| still using old software/processes, with managers that haven't
| written software in 20 years, if at all.
|
| In 2014 I worked at a company that switched to Git and then
| started measuring LoC to assess performance/involvement.
| Engineers took to committing/removing things like node_modules
| directories to make the data meaningless.
|
| It still happens, even today, quite a bit.
| jim_and_derrick wrote:
| sounds about right to me. i've had product managers argue
| that we fix bugs fast enough that we should not actually try
| to implement real solution (python2 to python3 upgrade). This
| lady is like 'every py2->py3 bug takes less than 2 hours to
| fix. Why would we do the solution that takes multiple
| sprints?'
|
| jaw dropped. since then i'm committed to being the biggest
| office space corporate schmo possible. let me cog it up, keep
| payin me 6 figs, lettin me work at home full time.
| Piskvorrr wrote:
| Last time I met this, it was 2008 IIRC.
| WalterBright wrote:
| Many people assume their manager knows what the employee is
| doing. They often aren't, meaning they go by what they can see,
| which is lines of code.
|
| The smart thing to do is to regularly keep your manager updated
| on what you're doing, especially if they don't come by
| regularly and ask you.
|
| Especially if you are WFH.
| drocer88 wrote:
| Rather than an integer number of lines of code, how about
| using a boolean : "it works" or "it does not work"? or "Does
| it meet the spec" or "it does not meet the spec"? Even a
| mediocre manager should able to test that one out.
|
| Code is often improved by removing code.
| touristtam wrote:
| Task completion should be the metric, not line counts,
| otherwise the incentive is creating the most bloated piece of
| software and the most comprehensive unit-test possible. Any
| system is going to be (ab)used by the employee to their
| benefit.
| qayxc wrote:
| Relevant post:
| https://news.ycombinator.com/item?id=23762526
|
| Task completion would also be abused, because it's too
| vague. It simply shifts the burden to the one formulating
| the task (e.g. preventing holes in the specification like
| missing performance or hardware requirements).
|
| Exaggerated example: if the "task" is to automatically
| deliver a report containing certain data and formatted in a
| specified way, the easy way might be an implementation that
| stalls the DB server for hours with deeply nested FULL
| OUTER JOINs on non-index fields.
|
| The task would be completed quickly and arguably correctly,
| since neither runtime nor memory requirements were
| explicitly specified...
|
| But you said it yourself, any system is going to be
| abused...
| methodin wrote:
| Indeed and it's why organizations that execute well treat
| this process as a collaboration rather than a dictation and
| report-back.
| WalterBright wrote:
| Organizations are always imperfect, which is why I strongly
| recommend taking the lead and being pro-active in keeping
| management informed of what you're accomplishing.
|
| Out of sight, out of mine <== don't let that happen to you
|
| I don't believe it is any coincidence that the highest
| compensated engineers I know also are highly visible
| through their own efforts.
| kevsim wrote:
| That's true. And I guess depending on the job/manager you
| could replace lines of code with "user-visible changes to
| app", etc.
| qayxc wrote:
| That'll be exploited as well. The number of pointless UI
| and feature changes would skyrocket without the app
| actually getting better or gaining meaningful
| functionality.
|
| Meta-metrics might be much more helpful, though harder to
| come up with, quantify and monitor. Things like defect
| rates, user reported incidents, user satisfaction, stuff
| like that.
|
| Things that cannot easily be gamed from within the
| development process and that are still directly linked to
| the success and economic viability of the product and its
| development methodology (though on a higher level).
| kevsim wrote:
| I wasn't suggesting that as a good metric. More like "if
| isn't LoC, it'll be some other terrible metric"
| csharptwdec19 wrote:
| I've seen that abused all the way to management, where
| meaningless new features are prioritized ahead of bugs
| VLM wrote:
| At most of the big companies I worked at (over 500 employees)
| there is a steering committee doing prioritization work and
| continuous integration test suites and an elaborate change
| control committee and process such that fixing a spelling error
| will take much more than two days.
|
| Whats nice about the proceduralism is you can document that the
| steering committee only meets once a week on Tuesday afternoons
| and change control meets on Thursday. And everyone knows the
| automated test suite on DEV takes about half a working day. So
| if a change can't be worked into the schedule in less than a
| day, it'll never pass CI testing before the change control
| meeting so it'll take more than a week.
|
| Whats bad, is mgmt would like you to complete multiple changes
| perhaps at the same time which always complicates the change
| control process especially if change #7 failed last week so
| company policy is to roll everything back and now we have 13
| changes, two weeks worth, to complete next weekend. Also whats
| bad, is knowing its a corporate nightmare to make any change,
| why did I make a mistake to begin with of having the buttons
| swapped or a misssspelling or whatever.
|
| I find the big metric now a days is backlog. Lets see the
| number of request tickets decrease this week instead of
| increase. That leads to intense pressure to roll multiple
| problems into one ticket.
| duderific wrote:
| 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."
| Nagyman wrote:
| 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.
| auxym wrote:
| And... guess who made the drawing (blueprints have not been
| used in a while)? An engineer. Probably using a vague spec
| by an architect, too.
|
| And I can assure you, they were not judged on the number of
| views or pages on their drawing, or on the number of
| variables in their structural calculations.
| runawaybottle wrote:
| Can you please help your brothers out and hint at what
| company this is so we can all avoid?
| ptx wrote:
| What if the construction workers just stack all the windows
| in one corner and pour all the concrete in the other? It must
| be just as good as building the house properly since they
| used the same amount of materials. If they just double the
| amount, the resulting pile of garbage will be twice as good
| as a functioning house.
| MauranKilom wrote:
| "If you wanted someone who writes as many lines as possible,
| you should have hired a secretary."
| bavila wrote:
| What an absurd response from your manager.
|
| 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.
| fireflux_ wrote:
| Oh, very much so. I don't think it's a matter of how "old" the
| industry is - there will always be people who have never worked
| with software folks or are familiar enough with the ecosystem
| not to make the assumptions stated in the article.
|
| This made me realize that working in a purely engineering team
| can sometimes be a perk. Not because technical people are
| "better", but because it leads to fewer frustrations like this
| one.
| femiagbabiaka wrote:
| https://speakerdeck.com/jallspaw/findings-from-the-field-dev...
|
| this reminded me quite a bit of this deck -- in particular, a
| focus on a shallow metric (in this case LoC) as a proxy for
| measuring complexity.
| bmcahren wrote:
| If you work somewhere you're defending yourself from this
| question repeatedly, just move on at your earliest convenience.
| They don't value quality developers and you'll eventually turn
| into the low-quality developer they've always wanted.
| eikenberry wrote:
| > I don't like having to fix bugs.
|
| ???
|
| I rather enjoy fixing bugs, particularly really hard ones. They
| can be fun logic puzzles that take some sleuthing to figure out
| and offer multiple pay outs... First time reproducing it.
| Figuring out the problem. Figuring out the best fix. Test case
| fail -> test case pass.
| ablanco wrote:
| It's really sad that people (managers) still thinks of code this
| way. Luckily this has never happened to me, but if it did I think
| it would be a great sign to change jobs.
| lmilcin wrote:
| Hindsight is 20/20.
|
| It takes more work to produce succinct code and it can take
| surprising amount of effort and care to land at a simple solution
| to a complex problem.
|
| My solution is to try to involve other people in my "process".
| This helps me transfer some knowledge of the decision process,
| helps debug ideas early on and hopefully is useful mentoring for
| the team.
|
| I can do this because I am senior engineer / tech lead at my org.
| For other engineers I highly recommend pair programming and
| constantly rotate developer pairs so that everybody can get some
| appreciation of everybody else.
| mirekrusin wrote:
| This is achilles heel of non-tech managers. You can link as many
| articles like that as you want, it will still be a problem. They
| may be more aware of it, but it will still be, daily struggle.
| Non-tech manager should be paired with tech-lead with high trust
| relationship for this not to be a problem.
|
| This example is just one case/symptom of much larger problem.
|
| Non-tech managers will only see fast progress on combination of:
| - poor developer - doing fast progress - with shitty code - on
| good quality codebase
|
| They will see tech lead/good coder as asshole in general, with
| poor performance in general, who for some unknown reason is
| respected for their code and sometimes magically ticks off hard
| problems quickly which "must be a coincidence, overestimated work
| to begin with or something like that" on combination of: - person
| who actually cares about the project - who repairs shitty
| code/tech debt - who thinks more deeply about the problem - and
| as a bigger picture issue, not just ticking off ticket with the
| lowest resistance possible - writes good quality code - if the
| problem breaks current abstrations, refactors abstration itself -
| who cares about readers of the code
| Piskvorrr wrote:
| Reminds me of that time a PHB decided to measure efficiency by
| kLOC. All the pull requests in the following week had a net
| negative line count.
| andi999 wrote:
| They PHB should put extra bonuses on kLOC, like 1k$ per 1kLOC,
| and watch the codebase increase exponentially and since
| documentation is better than code, double the amount for line
| of comments.
| Piskvorrr wrote:
| That's a literal Dilbert strip, 1998-ish, IIRC.
| [deleted]
| jedberg wrote:
| It's not just management that feels this way. A lot of junior
| engineers feel the same way. It's what leads to bloat because
| they assume "it can't be right" if it's just a small change.
|
| It takes a while for a lot of junior engineers to realize small
| elegant solutions are better, and requires good mentorship and
| code review to get there.
| jmartrican wrote:
| Because i wrote failing unit/integration tests before
| implementing the solution.
| pjettter wrote:
| I once reduced the amount of code for a client by ~75% and added
| usability and fault-tolerance. I wasn't even half done and they
| thought it was good enough. LoC is no measure.
| csours wrote:
| Because looking at this code feels like walking on broken glass.
| jiveturkey wrote:
| you think adding code takes a long time? try removing code!
| caymanjim wrote:
| 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 something, that
| doesn't mean it's secure, performant, scalable, or even
| functional beyond demoing with dummy data.
| chrisacky wrote:
| I literally just had a discussion with a client last week about
| a feature taking 2months to develop.in my time this week I
| built the UI, with no backend, and she asked why I quoted two
| months when it looks like it's already completed.
| AnimalMuppet wrote:
| Yes, it "looks like it's already completed" because you did
| the "looks" part. I get that you want to show them that part
| to get approval of the design approach, but it opens the door
| to misunderstandings like this.
|
| Maybe as part of the demo, you should demo that it
| *conspicuously fails to actually do anything", to help reset
| unrealistic expectations.
| D-Coder wrote:
| 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.)
| WaltPurvis wrote:
| https://www.joelonsoftware.com/2003/05/16/20030516/
| baddox wrote:
| Not even just the backend! Frontend interactivity itself can be
| very complicated, and it generally is not fully specified by
| design (do your design specs come with state machines?) A few
| things that are often missing from a Figma/similar are things
| like error states, loading states, handling longer text content
| than the mockup, and responsive design.
| Softcadbury wrote:
| And you can add paging, empty states, accessibility,
| security, browser compatibility...
| mring33621 wrote:
| Yes, very much like the time I replaced a getfakedata() method
| with a getrealdata() method and then management complained that
| it was much slower now.
| beckingz wrote:
| Maybe print out the data to show them the difference?
| pkilgore wrote:
| After this (and a few emergent race bugs), I started burying
| the equivalent of setTimeout(() => getFakeData(), 1500) in my
| similar code.
|
| Best part is, I'm almost certain to beat 1500, so I've gotten
| compliments that it "feels snappier".
| mcbits wrote:
| This reminds me of the infamous Speed-Up Loop.
| https://thedailywtf.com/articles/The-Speedup-Loop
| randomdude402 wrote:
| I am feeling suddenly inspired by this idea, so thanks!
| Kye wrote:
| Lesson learned: make demo functions slower on purpose so the
| real one matches or exceeds it. It's not even deceptive:
| you're setting realistic expectations instead of giving a
| false impression.
| cosmodisk wrote:
| It's all correct: 90% takes 5 days and the rest 10% will take 3
| months.
| symlinkk wrote:
| To me it just sounds like your frontend has a better
| architecture than your backend.
| zachrose wrote:
| I sometimes look at small mass-produced plastic items and
| marvel at how hard it would be to make one from scratch. If you
| showed me, say, a fluted plastic bottle of wite-out with a
| screw-on cap, I would have to assume you had a very expensive
| operation up and running that was already churning these out.
|
| In software we can put a few shapes on a screen in just the
| right context and people will believe there's an operation as
| sophisticated as the wite-out bottle factory behind it.
| RcouF1uZ4gsC wrote:
| Joel Spolsky has a great write up on this phenomenon [0]. The
| opening paragraph is great:
|
| > "I don't know what's wrong with my development team," the CEO
| thinks to himself. "Things were going so well when we started
| this project. For the first couple of weeks, the team cranked
| like crazy and got a great prototype working. But since then,
| things seem to have slowed to a crawl. They're just not working
| hard any more." He chooses a Callaway Titanium Driver and sends
| the caddy to fetch an ice-cold lemonade. "Maybe if I fire a
| couple of laggards that'll light a fire under them!"
|
| 0.https://www.joelonsoftware.com/2002/02/13/the-iceberg-
| secret...
| trav4225 wrote:
| Ahh, yes. This is so common in my experience as well!
| BareNakedCoder wrote:
| Has happened to me too more than once. I usually reply that the
| UI prototype is like a Hollywood movie set: what looks like a
| real building is fake, just a single wall. The real building
| still needs to be built. That explanation sometimes works,
| often doesn't :(
| ftio wrote:
| 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 wants to be
| left out of demo day multiple weeks in a row.
| [deleted]
| Jtsummers wrote:
| 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 it wasn't ready, and both the
| customer and I found that there were issues in that last 20%
| I hadn't reached.
| eikenberry wrote:
| 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.
| Jtsummers wrote:
| Yes. He came to my desk a week or so after he okayed the
| release of the software and took me to a conference room.
| I don't know how long he chewed me out for because I was
| red with rage but too terrified of losing my job to say
| anything. I've experienced similar rage with only one
| other manager [1]. He was 3 levels above me in the
| management chain, I really liked the two above me (the
| test manager, as I was in test at the time, and the
| software manager) and the guy above him [0]. I wanted to
| stay with them and I had a good friend there as well. But
| I did apply for a new job a couple months later, and left
| by the end of the year.
|
| It was my first professional development job and I
| learned a lot of things. One of the keys was this:
|
| Your boss and employer are not your friends. When you
| promise something to your friends, you owe it without any
| expectation of reward or return. But your employer owes
| you something for everything you give them. If they fail
| to meet their end of the bargain, that's on them and you
| are absolutely 100% free to leave. That can be money,
| time off, good working conditions, respect, trust, or any
| number of things. For me money was not primary (though it
| is nice): I wanted a good work environment, interesting
| work, and respect. Fail any of those and I will be
| looking for an exit, even if it's just a transfer within
| the same company. But respect is first in that. A boss
| who shows little respect to his employees is not someone
| I want to be around. I had that boss who chewed me out, I
| had another that kept me doing busy work for a year and
| kept saying worthless platitudes like "you're important
| to our work, we can't do this without you" when
| everything pointed to that being false. He was just
| empire building and trying to grow his direct report
| count, but it hurt those of us under him because he
| didn't have the work (but he did have the money) to keep
| us there. (I was still relatively junior at that job and
| stayed longer than I should've.)
|
| [0] The hierarchy was something like: VP of Engineering
| (several divisions below him) -> Chief of Engineer
| (Aviation) -> Chief of Software (Aviation) -> Chief of
| Testing (Aviation) -> Me; other production lines had
| similar chains below the VP.
|
| [1] When she was my manager I quit, or more accurately
| transferred to another group. Years later, I quit my last
| job for several reasons, one was her. She was _not_ in
| our division while I was in that position, but they 'd
| just hired her on. When I heard the name I had to verify,
| when I confirmed it was the same person I was ready to
| exit.
| caymanjim wrote:
| In a company that understands and embraces agile software
| practices, this works well. You demo small things that are
| done, and prototypes are understood as just mockups designed
| to drive future work. Alas not everyone in power gets it. In
| more egregious cases, I've been in adversarial environments
| where teams were pitted against each other to appear "more
| done." Obviously a recipe for failure. I'm fortunate enough
| to be able to be more selective in where I work now, and have
| the experience to drive the choice.
| [deleted]
| csours wrote:
| 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.
| irrational wrote:
| If they could be educated, they wouldn't be managers.
| ngngngng wrote:
| That's a funny comparison to demo days early in my career.
| The company I worked at had too much upper management that
| would hijack dev teams to make "cool" features constantly. We
| only had to make something good enough to appear like it
| worked in a demo though, because then that upper manager
| would get his bonus or look good to the CEO or CTO and we
| could move back to doing real work.
| core-questions wrote:
| > 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.
| ftio wrote:
| 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.
| manquer wrote:
| Reiterating what gp said , not all dev is like that,
| lesser you are doing IT and more comp science or any
| unfamiliar territory really it is harder to break down
| ahead of time .
|
| 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 .
| MattGaiser wrote:
| There is a reason that teams with mostly non-technical
| leadership deliver broken software as your choices are
| feature driven architecture with absurd glue or being asked
| "why isn't it done yet"?
| ddingus wrote:
| 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.
| caymanjim wrote:
| 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.
| ddingus wrote:
| 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.
| ftio wrote:
| Yeah, I could've been more precise about what I meant by
| "demo day." In my comment, I was thinking about the
| broader, often companywide demo days that many companies
| hold.
|
| I wasn't talking about intra-team demos to, say, product
| owners.
| commandlinefan wrote:
| > They simply don't understand that the backend functionality
| is what's doing the bulk of the work
|
| Even people who ought to know better don't understand this.
| [deleted]
| bsder wrote:
| > 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
| 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.
| bob1029 wrote:
| This is the best option. Creating low-fidelity UIs that prove
| the business functionality are faster to develop/iterate and
| provide an immediate signal to even the least technical
| individuals that the feature is still incomplete.
| dllthomas wrote:
| https://mamchenkov.net/wordpress/2012/07/23/a-duck
| WorldMaker wrote:
| "Sketch" themes or "xkcd" themes (named after the pencil look
| of the comic) can be quite handy for this.
|
| For instance, Bootsketch: http://yago.github.io/Bootsketch/
|
| I wish some of the bigger CSS frameworks would adopt sketch
| theming support as a "progressive" option, rather than the
| entire page all or nothing being Bootstrap or Bootsketch have
| the ability to add a "sketch" class to any element on any
| page. (Or maybe better yet, forcing sketch styles by default
| and needing something like a "final" or "final final" class
| everywhere, like the documents folder of someone that has
| never understood source control.)
| cmollis wrote:
| this happened to me.. except it was one line: free(ptr); / __here
| it is --- > */ ptr = 0x00;
|
| a classic.
| newshorts wrote:
| The assumption that asking for more information to recreate the
| bug is a lazy tactic to get out of the bug fix is also a terrible
| assumption and discredited the opinion IMO.
|
| Often times asking for more information can speed things up and
| lead to a quicker resolution.
| stx wrote:
| In my experience sometimes this is true, sometimes it is not.
| In some cases when asking for more information it takes much
| longer. Some of the reasons:
|
| After asking the question I get a meeting schedules where
| design by committee happens. The story or bug your working on
| gets completely redesigned. Sometimes in an illogical way.
| Requiring more questions.
|
| When working remote, like most of us right now, now I will end
| up waiting for a long time to get a response. I then must start
| some other story/task/bug. Trying to context switch multiple
| complex tasks at some point your productivity slows down.
|
| I have also received criticism for asking when I could figure
| it out myself even when figuring it out may have taken hours
| more time then just asking a yes/no question.
| labcomputer wrote:
| Sure, it depends on the context. But I've seen many examples
| where the reportee is asking for information that's already in
| the bug report, or can be easily inferred from the report.
| norenh wrote:
| I have worked on both sides of this in the enterprise world (as
| a support agent in the middle of dev team, as a end user and as
| a developer on the receiving end) and it is never simple. A bug
| report takes time to make and many times it might take time to
| reproduce or narrow down to a simple test case. A developer
| should of course get the information needed to fix a issue, but
| very often (s)he can find the issue with very little detective
| work if they know the product. The problem I've seen is that
| you have a fundamentally broken system where: 1. The devs don't
| really know the product in the sense that they do not use it.
| They have very little experience how it actually is used or the
| workflows and might not have good overview of the code base. 2.
| The support agents, if they exist, have little clue of either
| development or the product and just as a filter to remove the
| absolute majority of known issues but at the same time mess up
| the communication between end-user and devs 3. The end user
| have neither time or experience to test or report issues so you
| get very bad reports that vary wildly.
|
| When working as a support agent I have spent a lot of my time
| acting as a filter to stop making the end-users go mad with all
| the requests from the devs and preventing the devs from being
| flooded with crap reports (of course, some always slip
| through). That means a lot of time spent on reproducing and
| testing (and sometimes pointing out where the bug is in the
| code, even suggesting patches). But very few organisations pay
| for that knowledge and very few allow agents to muck around for
| a day with a tricky issue to make sure the devs can fix it
| without a major hassle.
|
| It is very easy to ask for more information as a dev, and very
| often it is needed, but a lot of the time it is just pushing
| the cost to the end-user when a minimal amount of detective
| work (or even a single quick test) would do the same and save
| everyone a lot of hassle. I would argue that in a lot of time
| when we, as devs, ask for more information we do it to push the
| issue into the future and to save ourself a minuscule of work
| now, not to have a quicker resolution.
| addicted44 wrote:
| Assuming the reporter is internal, you don't need them to go
| ahead and type out everything. A quick call with a screen
| share is all that's needed.
|
| Not even reaching out (again, assuming they are internal...if
| they are external then there are many other considerations)
| is just not smart IMO.
| halgir wrote:
| I know this can be nuanced, as pointed out in other replies.
| But as a product manager, I admit to having used this as a form
| of triage. People have told me they don't have time to write a
| proper bug report. I tell them if it's not important enough for
| you to spend five minutes reporting, it's not important enough
| for a developer to spend five hours fixing.
|
| I of course don't respond to everything as black and white as
| this, and I'm not expecting them to do the kind of
| troubleshooting that me or a developer could do much quicker.
| jedimastert wrote:
| Also, asking for more information lets you work on something
| else with more actionable feedback while they do so
| dgb23 wrote:
| I agree with this. If you are generally swamped with work,
| you need to do triage and possibly delegate work.
|
| This isn't perfect behavior. But in some situations the
| perfect solution isn't feasible.
| c0nsumer wrote:
| Unfortunately, working in a big enterprise world, I've seen
| both sides of this. After a while it becomes somewhat obvious
| if someone is legitimately asking for more info, or if they are
| just punting the ticket down the queue. (The former is when you
| can tell they are becoming focused whereas the latter seems to
| be more general, swirling questions.)
| newshorts wrote:
| True, having seen this as well, the motivation driving the
| dev does eventually become pretty transparent.
| bonestamp2 wrote:
| Agreed, although we (mostly) solved this a number of years
| ago. Our validation team has screen recording software
| running all the time. If they see an issue, they attach the
| video to the bug report. These videos dramatically improve
| everyone's ability to accurately report bugs and quickly
| resolve them.
| gshulegaard wrote:
| I too have seen the case when a developer will ask for more
| information in order to game the process. While this is
| arguably (and I would agree) a failure of the process since
| it incentivizes undesirable behavior, you can quickly wind up
| in a situation where there is a large cadre of developers who
| will reflexively ask for detail. In this situation you often
| have good "measured" performance across the engineering org,
| but there tends to also be a large swath of tickets which
| find themselves in limbo. Some of these tickets can take
| months to resolve when a day or two of concentrated effort
| could have resolved it.
| EsotericAlgo wrote:
| I suspect most developers have been on both sides of it. I've
| most often seen it as a delaying tactic where access/system
| bureaucracy prevents easy recreation. So generally
| dysfunctional enterprises.
| mastazi wrote:
| I agree with the general sentiment of the article, but the
| following is a big mistake IMHO:
|
| > Some developers would have immediately gone back to the person
| reporting the problem and required more information before
| investigating. I try and do as much as I can with the information
| provided.
|
| Some developers have a hard time with interpersonal communication
| but you can't isolate yourself if you're working in an org. That
| mindset will inevitably make you less effective (I learned that
| the hard way).
| pdpi wrote:
| "I'm sorry for the long letter, but I didn't have the time to
| write a shorter one."
| Slartie wrote:
| "Because I had to spend a lot of time to compile this long list
| of things that I also did while fixing the problem which are
| essential for a good solution but aren't immediately visible from
| the two lines I actually added so I would have something in hand
| to rebut this stupid question of yours!"
| whotheffknows wrote:
| Because product managers struggle to comprehensively understand
| value add and have instead replaced stating business goals and
| value add with bullying based micro managing tactics like
| counting lines of code and conflating other such arbitrary
| metrics related to code with having a 1:1 ratio of accomplishing
| the goal and do not respect the thought of troubleshooting,
| architecture design (unless you take another two days to turn it
| into a diagram presuming it needs to be consumed by some other
| party) and finding an elegant way to implement code to accomplish
| the goal as work because they can't see it, and they can't
| understand it because they are too busy collecting visual days to
| prove they are properly micromanaging you to take the time to
| learn the challenges inherent to the architecture and challenge
| at hand.
|
| Does that help?
___________________________________________________________________
(page generated 2020-07-14 23:00 UTC)