[HN Gopher] How to be a -10x Engineer
___________________________________________________________________
How to be a -10x Engineer
Author : surprisetalk
Score : 657 points
Date : 2023-04-04 11:42 UTC (11 hours ago)
(HTM) web link (taylor.town)
(TXT) w3m dump (taylor.town)
| ryukoposting wrote:
| > Trap 10 engineers in a futile skunkworks project.
|
| This is the business model of roughly 7 out of 10 startups.
| KronisLV wrote:
| I actually wrote an article a little bit like this one, a tongue
| in cheek piece called "The Unethical Developer's Guide to
| Personal Success": https://blog.kronis.dev/articles/the-
| unethical-developers-gu...
|
| In short, software development should most of the time be treated
| as a group activity and you should consider how the output of
| your own work affects those around you. While _you_ might not
| feel like documenting your decisions is a wise use of time, it
| could help others down the line. The same goes for choosing the
| simplest solution that works well vs going out and writing lots
| of "clever" code. Things like the ways how we communicate, how
| much nitpicking vs accepting "good enough" solutions all compount
| and have a pretty great effect on the output of others.
| garunski wrote:
| pro tip: post to the company general channel and ask who thinks
| there are people like that here? and what proof do you have?
| nico wrote:
| Just had a conversation about this.
|
| Let's let AI do all the busy work for us.
|
| I personally just want to think deeply, share ideas and connect
| with people.
|
| I don't want to be forced to do any meetings, presentations,
| tickets, code, documents...
|
| I do want to produce some of those things, as long as I feel like
| they help me in what I want to do.
|
| I want AI to do all the shit I don't want to do.
|
| I still want to work, interact with people, feel needed and feel
| connected. Just not forced to waste my time.
| patrakov wrote:
| The title contains an arithmetic error. What the article
| describes is a combination of 20 strategies (and explicitly
| advises to combine them!), each of which would have produced a
| -10x engineer. The result, therefore, is a -200x engineer.
| vrglvrglvrgl wrote:
| [dead]
| theery wrote:
| "Hold 10 engineers hostage in a technical discussion."
|
| Oh how I don't miss working in an office. Avoiding work,
| overthinking things, and overbuilding.
| havblue wrote:
| I've seen engineers who are good candidates for -10x... The moral
| of this story is, of course, if people are submitting work that
| creates more work, you must push back against them.
|
| Part of the issue is that intelligent people can be better at
| justifying work that wastes everyone's time. So if you're in a
| leadership position you really need to make sure people have
| their eyes on the prize and that they aren't padding their resume
| or needlessly doing tasks that worked at their previous job.
| Dowwie wrote:
| > Attract bright engineers and waste their potential. Undersell
| the difficulty of the project to management; oversell the
| project's usefulness. Tell management it's "almost complete"
| until they scrap it.
|
| People at every level of the organization, from the top-down,
| have done this since forever. The -10x engineer will choose a
| language that they're fascinated by, but have no production
| experience with, and then spend most of the budget building
| libraries that they assumed already existed in the ecosystem.
| "Almost complete" becomes "almost ready to start".
| cowmoo728 wrote:
| RDD (Resume Driven Development)
|
| The desire to add $TECHNOLOGY to run a relatively small site
| even though it will likely never scale beyond what a single
| postgres instance running on a mac mini can handle.
| koboll wrote:
| Unbelievably frustrating to be a junior or mid level engineer
| working with a senior dev who does this, watching it happen,
| maybe even arguing back and being overruled.
| poulpy123 wrote:
| No need for all that, it's natural for me
| swader999 wrote:
| These are valid points in the article and the comments. But
| people can change and it's very very rare you run into people
| that want to work in ways that upset everyone. The lead has to
| persuade the dev that this is counter productive and not
| acceptable. And of course sometimes this doesn't work and they
| need to go.
| irrational wrote:
| Who is the 1x engineer that all of these 10x, 100x, 1000x, -10x
| things are based off of?
| no-reply wrote:
| Wait for the piece, somebody is probably writing that
| adverbly wrote:
| Some options:
|
| 1. (Sum of total output) / (Count of engineers)
|
| 2. CS grad with a "B" GPA, 3 years experience, 1 year on the
| team
|
| 3. 50th percentile of all engineers
|
| 4. <- Me (or whoever the reader is)
| taink wrote:
| Don't forget your basic organization sabotage field manual:
| https://archive.org/details/SimpleSabotageFieldManualStrateg...
| darepublic wrote:
| Bike shed the crap out of everything in pr review (I have been
| guilty of this)
| londons_explore wrote:
| I find it is always best to keep reviews minimal, and any
| review comments should generally be "this isn't ideal -
| consider doing it this other way _next time_ - but LGTM ".
|
| Sure, the end result is a less perfect codebase. But
| considering code isn't the end goal - a working product with
| happy users is the end goal - imperfect code can be the right
| way to achieve that.
|
| And besides, all code that is still in production in 5 years is
| probably due a rewrite anyway - now that the company has
| pivoted a few times, the product has evolved, and the use cases
| aren't what they originally were. The computing landscape will
| also have evolved (eg. new language versions, new library
| versions, new hardware with different strengths and weaknesses,
| etc)
| the_sleaze9 wrote:
| There's a balance here, and for me it comes down to whether
| or not I'll be able to remember all of the narrow edge cases
| that this particular piece of code will introduce.
|
| Will braces around if statements matter when QA comes back
| with a regression 4 weeks from now or when Product has a new
| feature request? Probably not, so a "LGTM with a nit" is
| warranted.
|
| Adding a json request body to this GET request? Yeah, I'll
| have to remember that little bit of quirkiness, and quite
| frankly if the team member is adding bodies to GETs, I can't
| rely on them to remember that quirk or solve anything after
| that. So while that is technically a "style choice" since it
| does work, that's a blocked PR until Requested Changes are
| made.
| Jolter wrote:
| We must work in vastly different businesses. In five years,
| my company will still be selling similar products to the same
| customers -- likely the same product's successor model, and
| the code we write today may very well be the maintained
| legacy code then. To me, your approach sounds like hell
| because it means each line of that imperfect code will have
| caused a bug and/or forced a refactor commit.
| sublinear wrote:
| Got it. The -10x engineer is bad management who are in turn bad
| because the rest of the business is completely illiterate about
| anything even slightly technical.
| version_five wrote:
| That was roughly my takeaway, as well as personal experience.
| Even if there's an actual engineer operating at <= 0x, it's
| still mostly a management problem. There may be rare cases when
| someone is quietly subversive, where it would clearly be that
| ICs fault.
| sshine wrote:
| > the rest of the business is completely illiterate about
| anything even slightly technical
|
| It is that moment of realization that you're entirely
| responsible for the fate of the company, and you either think
| "I better tread carefully" or "This should be rewritten in
| Rust."
| weego wrote:
| "We need a new build system that's built on streams"
| nickpeterson wrote:
| Rust may still be a bit too pragmatic, perhaps you could use
| a language you wrote yourself?
| the_sleaze9 wrote:
| "Aaaand that's the container address orchestrator -- it's
| written in Haskell by that one guy a few years ago."
| ilyt wrote:
| "We wait for it to break for last 3 years just to have
| excuse to run k8s"
| mkl95 wrote:
| It reminds me of some Python threading monstrosity a guy
| wrote at my first job. He said something like "this is my
| own take at async".
| ptx wrote:
| To be fair to that guy, the Python standard library
| provides a multitude of incompatible takes at async
| already, none of which covers all common use cases. The
| newest take (asyncio) doesn't integrate with external
| event loops, so unlike similar libraries in C# and
| Kotlin, it doesn't work with GUI libraries, not even the
| one in the standard library (tkinter).
|
| The third-party asyncio alternative Trio, on the other
| hand, has recently added "guest mode" [1] to plug in
| external event loops, so maybe that will become the one
| true way to do async.
|
| [1] https://trio.readthedocs.io/en/stable/reference-
| lowlevel.htm...
| photochemsyn wrote:
| A lot of these look like Goldilocks problems, e.g.
|
| > "Waste 400 hours of engineering on bad architecture: Give zero
| consideration to how your system design will evolve over time.
| Alternatively, drive your team obsess over architecture decisions
| so that they don't have time to test their hypotheses."
|
| A complex project with many people working on it in different
| teams calls for modularization and well-defined interfaces, so
| working out the architecture up-front does matter, and changing
| it down the line will have huge costs. Staged progession is the
| answer, probably, which is why you'd want to have a meeting where
| everyone agrees, "this is the architecture we're going with, now
| everyone go build the modularized widgets that fit into this
| architecture, here are the stable interfaces to build to." Screw
| that up and you end up with tons of wasted effort, but dithering
| around and never making a decision is no better.
|
| Some of the other stuff relates to the 'build team spirit'
| corporate mentality which is kind of culturally variable - some
| people love it and some people hate it. Minimal is better, IMO.
|
| Then there's the 'basic technical proficiency' category of
| problems, e.g. recompliling the entire collection of source code
| every time you make a lttle change because the build
| configuration in the makefiles is incorrect etc. That's probably
| the easiest category to fix, some people just have holes in their
| knowledge and those can be filled. Here is where the company jerk
| is a major liability, though - you want people who can teach
| others how to improve their workflows without engaging in any
| condescending / egomaniacal / prima donna behavior.
| blantonl wrote:
| I love the skunkworks reference. Every time I see something like
| this in a 3 person startup, I just want to grab someone by the
| neck and tell them:
|
| "Bro, your mobile app redesign to Flutter is not a 'skunkworks'
| project. Unless you are Lockheed Martin, or Boeing, and the
| project will approach a trillion dollars of spend, has the
| capability to eliminate millions of human lives, and requires
| 1000 security managers and 25,000 Top Secret/SCI employees you
| ain't doing no 'skunkworks'"
|
| Cracks me up.
| senko wrote:
| Good list. Should be called "How to be a -10x Manager" though,
| since the majority of the bad decisions listed there are under
| the manager's purview.
|
| Reminds me of the CIA sabotage field manual:
| https://www.hsdl.org/c/abstract/?docid=750070
|
| On another note, many of the items there are "create pointless
| X". It's actually a thin line between "important X" and
| "pointless X" and many people will disagree where it actually
| lies (as evidenced in the comments here).
| Xeoncross wrote:
| I've been surprised how many -10x Engineers exist, they have
| almost always moved into management.
| Balgair wrote:
| The Gervais Principle in action
| dividedbyzero wrote:
| This reads a lot like one of those WW2 low-risk sabotage manuals.
| wmanley wrote:
| I see what you mean:
| https://regmedia.co.uk/2021/01/05/simple_sabotage_field_manu...
| ZooCow wrote:
| OSS Simple Sabotage Field Manual
|
| https://archive.org/details/SimpleSabotageFieldManual/page/n...
|
| Pages 28-32 are the most referenced but the rest is interesting
| too.
| Manjuuu wrote:
| That's a perfect metaphor.
| rvba wrote:
| This looks like the behavior of management in a company where I
| worked.
|
| The business was relatively 'boring' - core product would move
| slowly. But management kept hiring bad people and losing
| talent. At some point the ship started to slow down.
|
| Those smart people quit to competitors and even some launched
| their own company that is growing fast.
|
| No bad employee was ever fired, their tasks were just allocated
| to the few good ones. Who started to quit en masse.
| pablok2 wrote:
| This is hilarious, good ol' irony
| yuppie_scum wrote:
| As a manager, I'd rather have a 1x engineer who spends that x
| doing exactly what I want/need.
| f0e4c2f7 wrote:
| In David Graeber's book Bullshit Jobs he categorizes this type
| into a phylum of "bullshit generator"
| amelius wrote:
| This holds more for managers than for engineers, in my
| experience.
| tourgen wrote:
| [dead]
| m3kw9 wrote:
| Most of us are guilty on at least one of these to a certain
| extent
| biosboiii wrote:
| You forgot the most crucial part to making a career in big corps:
| After you fucked everything up "rescue" the project with
| witnesses.
| ilyt wrote:
| And get promotion over guy that didn't pushed broken shit on
| production in the first place.
| eschneider wrote:
| Meetings are a huge opportunity to either value-add or value-
| subtract and a little planning can go a long way. Some pointers:
|
| * Have an agenda and circulate it along with the invite. Let
| people know what you want to discuss so they can prepare. * Know
| what outcome you want from a meeting and let people know in the
| invite. Again, it lets them come prepared and even better, make
| pre-meeting suggestions. * Think about who needs to be involved.
| Do you really need everyone, or just one or two people. Again,
| agenda lets folks know if they can contribute or if someone else
| needs to be pulled in.
|
| It's not that meetings are bad, but bad meetings waste lots of
| people's time. Good meetings save time.
|
| Oh, and write down meeting minutes and publish results. The
| person you're recording this for is usually yourself. :>
| benknight87 wrote:
| yeah this is why I always work solo. Microservices built by small
| teams where everyone has a distinct role.
| chasd00 wrote:
| -10x software engineer is someone who refuses to recognize and
| learn from their mistakes and also refuses to learn anything new
| or different.
| vardump wrote:
| Just need to put two of these -10x engineers working together.
| The results should be amazing!
| [deleted]
| VulgarExigency wrote:
| Thanks for sharing! I'll start putting everything here in
| practice immediately. Some of these are already widely practiced
| at the company I work for, though, so I probably won't stand out
| too much.
| JCharante wrote:
| > Mock function calls until no original code runs.
|
| This one hurt personally. I didn't write it, we maintain it,
| but we have no time to go back and write real tests.
| VulgarExigency wrote:
| As I've become more experienced as a programmer, I've grown
| to hate unit tests that rely on mocks. They don't test a damn
| thing and they calcify code by making it a chore to update,
| since you have to update all the useless tests that don't do
| anything too.
| rc_mob wrote:
| From my experience the lowest productivity engineers are the ones
| that just never talk. I understand being an introvert but we all
| chat about things we have passion for.
|
| Anyways ive seen so many "programmers" that sit silently in
| meetings and also just do not produce good code. Usually they
| produce bad code that I have to revert.
| Aperocky wrote:
| I have corrected design (that fortunately were not implemented
| yet) where an API were to make parallel calls to the same
| table, and after all of them returns, calculate the pagination
| via combination and math.
|
| I replaced it with an index, it was a pretty straightforward
| index as well, imagine the pain if the original design was
| somehow implemented.
| francisofascii wrote:
| That description sounds more like a 0x or -1x engineer.
| Consider yourself fortunate to having never worked with someone
| who is closer to -10x.
| bradwood wrote:
| What about the 0.01x Engineer? Much easier to achieve I think: do
| as little as possible without getting caught.
| surement wrote:
| basically the 0x engineers the article talks about wrt
| opportunity cost
| Manjuuu wrote:
| The "don't rock boats" is really what can slowly destroy
| companies. The -nx engineers know a lot of other -nx engineers
| that can come onboard until the stable boat just sinks.
| TrackerFF wrote:
| It's not that bad engineers only socialize with other bad
| engineers - but rather that many naive and inexperienced
| engineers are much too kind, and will try to onboard every
| friend or relative they know, without ever having worked with
| them - they're basically vouching people blindly.
|
| This is something I've seen myself: Clueless manager hires the
| wrong man for the job -> wrong man is utterly clueless on how
| things work, what needs to be done, and flounders around for a
| couple of months -> wrong man decides that, hey, I know this
| one guy that seems to know his sh!t, let's get him onboard.
| Just fast-track him through the process.
|
| Turns out the new guy is also wrong man for the job, and
| doesn't know what to do. So now they're two (wrong) guys doing
| busywork while the ship is sinking.
| HPsquared wrote:
| To extend the boat analogy, I suppose it's impossible to know
| the stability of a boat without rocking it a bit.
| duxup wrote:
| Sometimes things just need to fail naturally and some rando on
| a mission to "rock the boat" is a net negative.
|
| Picking your fights is an important thing to learn too,
| throwing a fit over everything "wrong" can be terrible for
| everyone... even if you're right every time.
| AnimalMuppet wrote:
| People have limited bandwidth. Especially, it takes a lot
| longer to fix something than it does to just point out that
| it's broken. You can be right in every problem you point out,
| but if you point them out all at once, nobody can fix all
| that. Pick _one_ and point it out (preferably also suggesting
| a path to fixing it), and then work with people to get it
| fixed. Keep your mouth shut about the others while this is
| going on.
| Manjuuu wrote:
| > Picking your fights is an important thing to learn too,
| throwing a fit over everything "wrong" can be terrible for
| everyone... even if you're right every time.
|
| Agreed, most of the times it does not even make any sense in
| the grand scheme of things to go on those kind of crusades.
| Also, don't be the saviour no one is asking for.
| commandlinefan wrote:
| > Decide that existing solutions aren't quite what you need
|
| But
|
| > Add dependencies that demand 400 hours of maintenance.
|
| These suggestions conflict with each other - if you're one of
| these "don't ever write code if somebody wrote something somewhat
| similar" types, you're also the one adding terabytes of
| dependencies that have varying levels of documentation and stop
| being supported at arbitrary points in the future.
| dt3ft wrote:
| Mock everything until original code no longer executes (which was
| supposed to be tested): this one hits close to home. If
| everything is mocked, what are you testing really? Gah.
| noobcoder wrote:
| Frankly there's a kernel of truth in here. We've all worked with
| that one engineer who seems to have a knack for creating chaos
| and confusion. But let's not forget, it's also important to
| acknowledge the value of a good -1x engineer - they're the ones
| who make us appreciate the +1x engineers even more!
| atoav wrote:
| I think as engineers we have to realize a few things:
|
| 1. Unless you are working alone and for yourself good
| communications are more important than most engineers will admit.
| The thing is: the quality of communication does not necessarily
| correlate with the quantity or the duration of it. And depending
| what role you play, _you_ might not need a lot of communication
| in order to get a clear picture, while others might need more
| (for you: unnecessary) communiation to get on the same page. The
| drummer of my band always used to say there shouldn 't be that
| much discussion about what we are playing, which is super easy to
| say if you don't need to harmonically integrate with other
| instrumentalists.
|
| 2. Every single one of us is in danger of dialing the degree of
| complexity too far, or not far enough. Every single one of us is
| in danger of doing things a certain way because we try to make
| them nice, while that makes them technically unmaintainable. Code
| is communication as well. Communication with your collegues or
| yourself in the future. Good code is efficient, reliable and
| communicates well. Sometimes we have to sacrifice a little bit of
| one for the other, but clear code and e.g. efficient code should
| not be seen as opposites, but as a multidimensional problem to
| which there are solutions that work better on both fronts and
| solutions that suck on both fronts.
|
| 3. Context. Many engineers I have met have a hard time explaining
| some concept or problem in a way that it is understandable.
| Either they dive in way to hard and assume everybody knows what
| they know or they will start explaining it and get side-tracked
| and end up talking about something entirely else. Giving someone
| a clear image of where we are and then zooming in on the detail
| in well-sized steps is a skill I wish more people had. This skill
| also helps when debugging, because you will check your zoomed-
| out-priors first and then bifurcate the problem space as you zoom
| in.
| jsutter909 wrote:
| [flagged]
| hardwaregeek wrote:
| This does underline a key point. Avoid unnecessary perf hits in
| your workflow. The whole Interstellar meme of "this little
| maneuver is gonna cost us 10 years" is very much true. I've
| worked on high performance teams that did the wrong thing
| strategically and it ended up effectively slowing down their pace
| massively. It doesn't matter how fast you're running if you're
| running in the wrong direction.
| Kon-Peki wrote:
| I've seen the other side. 2/3rds of the devs I work with have no
| idea where the money in their paychecks comes from, and couldn't
| care less.
|
| TLDR: customers don't pay for beautiful, elegant code dealing
| with the happy path only.
| trash_cat wrote:
| Excellent manual when it doesn't matter if you pretend to work or
| do the work and the outcome is the same.
| arnejenssen wrote:
| You mean a 1/10*x engineer?
| tadzikpk wrote:
| Oh, you forgot "publish a service with undocumented limitations
| that others are required to use". You can easily achieve -10x
| that way!
| herbcso wrote:
| Wait, was this NOT a belated April Fool's joke?
| cowmoo728 wrote:
| one other to add:
|
| claim high-value projects/tasks, but don't finish them. when
| another team starts working on the same problem, schedule a
| meeting over their head and tell the other team's director level
| that you're already working on it and it's a waste of resources
| for multiple teams to work on this simultaneously.
| maayank wrote:
| "Explain code in private messages. Write wikis that nobody uses."
|
| What the reasonable alternative though? What's the happy medium?
| ejb999 wrote:
| >>Explain code in private messages.
|
| ...and this is the natural result of the 'no comments allowed
| in the code' nazi's that seem to permeate lots of
| organizations. For the life of me I could never understand that
| particular bandwagon.
|
| I for one love it when I go back into my code after a few years
| and a few well placed comments remind me why I did what I did
| last time I worked on it.
| Ensorceled wrote:
| I took over leadership of a project where the previous CTO
| was a "code should be self documenting" proponent and
| enforced a comment limit with a precommit hook. I think I
| made some of the developers cry when I asked why there were
| so few comments.
| ejb999 wrote:
| even worse, I worked on a project where you were not
| allowed to have comments in code, but if you really felt a
| need to explain something, you could put it in the projects
| readme.md, referencing the file and line number and why you
| did what you did.
|
| Talk about a bone-headed outcome of claiming 'we don't
| allow comments in our code' mentality.
| Ensorceled wrote:
| OMG. I fell afoul of commenting AND coding "standards"
| when I used Duff's device in an embedded system and my
| comment was something like.
|
| /* Using Duff's device see <reference> for speed and code
| size */
|
| The poor developer assigned to replace it with "better
| code" had an impossible task because they couldn't find
| anything to replace it that wasn't either much slower or
| much bigger.
| nyob wrote:
| I would suggest you to read Clean Code by Robert C. Martin.
| There's a whole chapter about comments in the book.
| ssrc wrote:
| I try to write informative comments. That said, 99% of the
| comments I see are
|
| * Useless, like "locks the mutex" before a mutex.lock().
|
| * Contrary to the code, like "This parameter contains the
| proc name without the instance" and then the parameter does
| contain the instance.
|
| * Dubious, like it's not obvious what the comment means nor
| if what you are doing follows the comment or not.
|
| Worst thing is when the code and the comment contradict and
| there's no good reason to trust one over the other in what
| the code _should_ do (never go to sea with two chronometers).
|
| I suppose it depends on the codebase you are working on. If
| it's your own code the likelihood of you agreeing with the
| comment increases, ofc.
| Frotag wrote:
| Zero effort solution is to have permanent group chats so
| background info like discussions on requirements are
| searchable.
| anilakar wrote:
| When a coworker does not understand what a function call does,
| you add a verbose enough comment directly to the code.
| articsputnik wrote:
| In that context, I love giving complete responsibility to a
| small, integrated team of designers and programmers. They define
| their tasks, adjust the scope, and work together to build
| vertical slices of the product one at a time. This completely
| differs from other methodologies, where managers chop up the work
| and programmers act like ticket-takers.
|
| Instead of having 10x engineers, make the team 10x. Shape Up
| (https://basecamp.com/shapeup/0.3-chapter-01#making-teams-res...)
| by Basecamp is the best resource I've seen on that topic.
| sawyna wrote:
| Funny enough I have been dealing with this situation at work
| exactly right now. It is insanely annoying to be in such an
| environment.
|
| Obviously, I'm the odd man out for saying a project can be done
| by 1-2 engs in a month. This said project is being currently done
| by 10 engs who are all writing boilerplate code since two months.
|
| The management is not taking responsibility and I can't believe
| everything that is said in the post is fairly accurate.
| tbjgolden wrote:
| "Don't settle for dead-weight." - amazing
| liamN wrote:
| > To ensure developers are context-switching, recompilation
| should take at least 20 seconds.
|
| So true. But only 20 seconds? The project im working on takes 20
| MINUTES to compile for any code change. I constantly forget about
| it while trying to get something else done in the mean time. It
| frequently takes whole days to track down and verify simple
| issues.
| DonHopkins wrote:
| Here's Lars Brinkhoff studying to become a 10x programmer:
|
| https://twitter.com/larsbrinkhoff/status/1642569175657771009
| DiscourseFan wrote:
| A friend of mine accidentally wiped out over 100k hours of other
| researcher's computing operations the other day, does that make
| him a -100,000x engineer?
| lightbendover wrote:
| Probably not, unless they did that in their first hour of
| employment.
| drewcoo wrote:
| Whoever is responsible for backups but didn't set them up might
| be.
|
| The person who wiped out the data should be thanked for
| uncovering the serious problem.
| ok123456 wrote:
| No. You'd call him unemployed.
| ilyt wrote:
| Nope, only the person that didn't thought about backups of
| that.
| regularjack wrote:
| If that data would be wiped by a fire instead, would you call
| that fire a -100,000x a engineer?
|
| Accidents happen, the fault lies on whoever did not backup the
| data.
| DiscourseFan wrote:
| I suppose the author of the article would, though.
| yunwal wrote:
| Most of these are either management issues or written as if the
| person is acting in bad faith. But there are plenty of engineers
| who are 1) smart 2) driven, and 3) well-meaning that still find
| themselves in this position
|
| One time I found myself in this position was overseeing an
| infrastructure migration for scaling reasons. The goal was to
| have it done before we hit scaling limits, and we had a team of 2
| people and a fairly complex architecture. From the start, I
| suspected it might be difficult to do with the current staffing,
| even after extensive planning, but I underestimated what the
| costs would be to not completing the project on time.
|
| I was told by my manager that completing the project before
| hitting scaling limits was life or death for the company (it
| wasn't, I know this because the sales team didn't hit their
| targets and we survived). I now realize this was my manager
| attempting to motivate me to take on a tough project, rather than
| real truth. Had I pushed back harder, inquired about company
| financials, this would have been exposed as not true.
|
| While we eventually ended up completing the project, we completed
| our largest phase of hiring while in limbo between 2
| architectures. The company became disorganized, accepting large
| amounts of tech debt as it was tough for new hires to understand
| what the "correct" thing to do was, and many people ended up
| adding to the legacy architecture in cases where they didn't need
| to. It was a mistake that likely cost millions, even tens of
| millions in my eyes.
|
| The correct thing to do, of course, was just to insist that we
| couldn't scale until we trained or hired more people to help.
| Limiting growth is often seen as unacceptable in startup culture,
| but IMO should be considered more often.
| agentultra wrote:
| I don't agree that writing and communicating designs, plans, and
| discussing problems or solutions is a waste of time. Our job
| isn't to blast code out and not talk to anyone (unless you're the
| sole developer on a project, but even then you should still
| write). Writing is thinking! Thinking is our job. Code is the
| artifact.
| stan_kirdey wrote:
| ... -> hallucinate your answers to the team mates, as if you are
| an LLM
| TAKEMYMONEY wrote:
| Can we go back to calling it "changing" instead of "pivoting"
| again?
| [deleted]
| flumpcakes wrote:
| > Ask your team to perform tasks that resemble work. Common
| examples include presentations, diagrams, and ticket management.
|
| I'm as salty as the next guy, but in my experience it has been
| the sub-par employees who are the ones that _don 't_ do this.
| Ticket management is not busy work, it's a necessity for everyone
| to keep updated. Presentations and diagrams are tools to
| communicate. I can safely say that by far the most waste I've
| ever seen has always come down to poor communication rather than
| anything actually business or technical related.
| ResearchCode wrote:
| It's busy work if you do it more than 1 hour any given week. If
| you do it full-time, you're something like a -10x engineer.
| wpietri wrote:
| > Ticket management is not busy work, it's a necessity for
| everyone to keep updated.
|
| Yes and no. If I oversimplify one of the important Lean points,
| you can divide activity into 3 buckets: 1) value-creating, 2)
| necessary waste, 3) pure waste. It's important here that
| "value" is always measured from the customer perspective.
|
| For example, imagine a hamburger joint. You have ordered a
| cheeseburger. The person at the grill cooks a patty for you,
| puts some cheese on it, and assembles a burger. Then somebody
| else walks that burger to you. Except they get distracted after
| they've picked it up, so they end up walking to the back before
| coming up to give it to you.
|
| Making the burger is _value creating_. You wouldn 't want a raw
| patty, and you want it put together right. Walking the burger
| to you is _necessary waste_ , in that moving the burger does
| not increase its value, but we have to do it to deliver value.
| The little stroll to the back is _unnecessary waste_ in that
| you could receive the same value without it. Make sense?
|
| With that framework, let's think about software. Ticket
| management is not a value-creating activity. If I do an extra
| hour of ticket management, that does not guarantee increased
| value. At best, it's necessary waste: I just can't figure out
| how to get you what you want without N hours of ticket
| management. But quite often it's unnecessary waste, labor
| performed for some purpose other than customer value. For
| example, a lot of planning activity is about making high-status
| people feel important. Or part of somebody's ongoing battle for
| increased status. Or the downstream consequence of previous
| unaddressed failures causing distrust.
|
| So can ticket management be _necessary_ waste? Sure. But it 's
| often pure waste. I've done whole companies with no more ticket
| management than you get out of a bunch of index cards on the
| wall. [1] And we got there by relentlessly cutting the waste of
| heavier processes, something that a lot of companies won't even
| think about, much less attempt, because there productivity is
| relatively unimportant.
|
| [1] e.g.: https://williampietri.com/writing/2015/the-big-board/
| bstpierre wrote:
| If the ticket is a direct conduit to the customer, I think
| you could argue that ticket management in the form of asking
| clarifying questions so that you build the right thing (or
| fix the right bug) is creating value?
| michaelt wrote:
| _> Ticket management is not busy work, it 's a necessity for
| everyone to keep updated._
|
| I would say that rather depends on how much of it you do.
| flumpcakes wrote:
| Oh, I see... I just assumed people read tickets and did the
| work and updated the ticket?
|
| For example, I went through a dozen tickets this morning and
| 96% of my time was spent either writing updates or doing the
| work the tickets were talking about. 4% probably went to
| reading the ticket itself and placing it in the correct place
| after updates/work. That 4% means meetings later will flow
| faster, and I don't have to remember or write down details
| and statuses of things somewhere else.
|
| Are people really wasting time on 'ticket management' that
| isn't as I've described?
|
| Edit:
|
| I've spent some time thinking about this, and despite being
| the org owner for our companies Azure DevOps instance I'm
| actually firmly in the 'Ops' camp of Ops<->DevOps<->Dev. My
| job is mainly Ops and I do some DevOps/SRE work on the side
| as the pragmatic-infrastructure-guy. I often see lots of
| nonsense done in the Developer camp. I think why I don't see
| the downsides of tickets is because I come from the
| background where tickets are more Help Centre-like. It's just
| pieces of work that needs doing or people need help with. If
| the help centre started arguing about if something is 'high'
| or 'critical' or spent 50% of their time just 'managing
| tickets' then they would flat-out just get fired. I guess
| that's the cultural difference between HC/Ops and 'Dev' that
| I wasn't really seeing before.
| ilyt wrote:
| Make everything, even a 1 min fix a ticket and insist it's
| under right category and right project, the time is
| accounted for, and each developer have to report 8h time
| worked a day and you can have plenty of time wasted on
| ticketing
| robertlagrant wrote:
| If you're making a change without saying what it is or
| how to test it, and not writing an automated test to
| cover it then that would be a problem. It might be 1
| minute in code, but that doesn't mean it's a 1 minute
| fix.
| mnd999 wrote:
| It depends. Maybe the 1 min fix is to add a missing test
| case for something that already works. Spending 20 mins
| creating a templated Jira for that is a waste of time
| imho, but it depends on what you do. In some places that
| have externally audited traceability requirements that
| would be necessary.
| robertlagrant wrote:
| Yes, I agree with that. I'd say that changes to the
| running codebase would need (slightly) more formality
| than changes to the test codebase, but yes, if tests are
| a feature e.g. because they feed into regulatory output,
| then they should also be ticketed.
|
| I don't find that a Jira ticket takes more than 2 minutes
| to write though, so maybe there's a difference in terms
| of number of mandatory fields.
| michaelt wrote:
| 2 minutes? That's barely enough time to load the Jira
| ticket creation page...
| robertlagrant wrote:
| Hah! Hit create and the popup opens. Unless you have a
| load of plugins installed, in which case tell your IT
| department off.
| ilyt wrote:
| The commit or comment is enough for that.
| dividedbyzero wrote:
| I mean, first we really need to align on which Jira
| components to add to that ticket of yours, because we use
| them to reflect the products that benefit from the change
| and you should get in touch with the Automated Horse
| Warehousing PO whether changing the hue on the "Apply Now"
| button on the About Us page impacts their Siemens
| automation codebase. Also, you didn't fill out the seven
| big free text fields with the proper info in the proper
| format, and while I understand you physically can't know
| half of this before making the change, you must or the
| ticket can't advance from "Backlog" to "Under Consideration
| for To-Do" in our pre-grooming meeting on Thursday. Oh and
| I think the update comment you wrote under BLLSHT-173 got
| auto-deleted because you didn't follow our Task Update
| Formatting Guidelines, could you reformat and post again?
| quacked wrote:
| I see you worked for both of the past two companies I
| worked for as well.
| javcasas wrote:
| I recently pushed back on discussing if an already-
| completed ticket was really a bug, or a feature to work
| around a limitation in the browser.
|
| I mean, that ticket was messing so hard the tech debt
| statistics! Or so that claimed the PM.
| swiftcoder wrote:
| There are definitely corporate cultures where updating
| ticket status at regular intervals is higher priority than
| actually working the problem in the ticket.
| rlpb wrote:
| Of course it is. That means that you work on the problem,
| but when a regular interval arrives, you stop working on
| the problem to update the ticket instead. Once updated,
| you go back to working on the problem. That's how status
| updates are supposed to work.
|
| Inverting the priority would mean that you never update
| tickets until you're done fixing the problem. That might
| be possible in small organisations or for small problems.
| Everywhere else, it's necessary to provide updates from
| time to time before the problem is solved.
| swiftcoder wrote:
| That really depends how short your management chain
| thinks the intervals are
| fourseventy wrote:
| I found the scrum master
| rlpb wrote:
| Ha. No.
| ResearchCode wrote:
| Do Linux kernel developers do that?
| yamtaddle wrote:
| If you want daily updates on normal tasks, you're just
| wasting a bunch of people's time. Under ordinary
| circumstances, that stuff cannot possibly be actionable,
| and tracking data that's not actionable is just wankery.
| I don't mean keeping people directly working on the tasks
| in-the-loop with one another and surfacing blockers,
| which shouldn't need formal process beyond _at most_ a
| five-minute daily standup, I mean up-the-chain status
| updates. Wanting to watch the little Jiras move through
| the flow chart on a daily basis is just PMs and managers
| wishing they were playing Starcraft or something instead
| of doing work.
|
| Given that, if your tasks are taking long enough that any
| but very-rare outliers span more than a couple status
| updates (which shouldn't be needed more than about
| weekly, under normal circumstances) then your tasks are
| too big or you've got some serious process issues making
| everything take far longer than it should.
| ryandrake wrote:
| From the project manager's point of view: I think it
| depends on the urgency/priority of the bug. If it's a
| production outage that's costing $N million a
| microsecond, yes, I want status updates multiple times
| daily. If it's a nice-to-have bugfix, update it whenever
| you can, I don't care. If it's somewhere in between, I'd
| expect an update frequency proportional to the
| seriousness of the problem.
|
| Bottom line is that in any remotely serious business,
| status has to be written and communicated to the
| executives. It's not optional. There's the easy way: use
| the ticketing system, leave comments, mark things as
| resolved, so the managers can just read the ticketing
| system's reports and leave you alone. And there's the
| hard way: don't use the ticketing system, and have an
| annoying guy like me "pinging" you for updates and what's
| the progress on this and what's the status on that. We
| both like the easy way so let's settle on doing that!
| yamtaddle wrote:
| > From the project manager's point of view: I think it
| depends on the urgency/priority of the bug. If it's a
| production outage that's costing $N million a
| microsecond, yes, I want status updates multiple times
| daily.
|
| Right, that's why I specified "normal" and "ordinary"
| tasks. Outages are another matter.
|
| > Bottom line is that in any remotely serious business,
| status has to be written and communicated to the
| executives. It's not optional. There's the easy way: use
| the ticketing system, leave comments, mark things as
| resolved, so the managers can just read the ticketing
| system's reports and leave you alone. And there's the
| hard way: don't use the ticketing system, and have an
| annoying guy like me "pinging" you for updates and what's
| the progress on this and what's the status on that. We
| both like the easy way so let's settle on doing that!
|
| Devs aren't in the ticketing system all day. They close
| it because they're all bloated as hell and eat system
| resources like mad, only opening it when strictly
| necessary, which then takes forever. They take longer to
| navigate it than you do, because they're not in it all
| day. They dread it because ticket workflows are often
| convoluted and hard to understand for anyone who's not in
| the ticketing system all day, and because they're all
| designed in such a way that it's weirdly-easy to
| accidentally press a button or drag something and mess
| things up in ways that can be tricky to fix or even to
| understand what's happened, sometimes without even
| noticing one has done that--it usually feels like trying
| to collaborate by using the PM's RDP-shared Windows
| desktop, covered with directories and text files arranged
| just so.
|
| It _is not_ the "easy way" to them, it's easy _for you_
| , and only you--otherwise, they'd use it! If your devs
| are any good, I guarantee they're communicating a lot,
| just not where you want them to, because it _is not_ easy
| for them. Slack, email, git logs, PRs, quite possibly a
| shadow-ticketing system that 's not a resource-hogging,
| confusing pile of crap in really pathological cases
| (probably the one attached to any Web-attached source
| management system you're using)
|
| I agree that status needs to be communicated, but if
| that's more than about weekly _under normal
| circumstances_ then it 's because someone's screwing up,
| and it's worth remembering that your "easy" as someone
| who's in Jira (or whatever) all day isn't someone else's
| "easy".
|
| Their "easy" would be you letting them use a ticket
| system they find actually-usable, and then reading that
| and translating anything that's happened there, into the
| one that you like but that doesn't work well for them. Or
| just figure out a way to use the one they like--you're
| one person, they're several.
|
| [EDIT] It's also worth considering that those kinds of
| high-visibility-to-managers systems are always going to
| be a bit bullshitty. People will omit things or even lie
| on them at higher rates than they will on purely-internal
| communication tools, which is part of why people don't
| like to use them for their _actually important_
| communication within a team. Letting the team communicate
| where they like and then translating that into Manager in
| the high-visibility system will get you more-accurate
| information, and you can decide what to do with it.
| swiftcoder wrote:
| > If it's a production outage that's costing $N million a
| microsecond, yes, I want status updates multiple times
| daily.
|
| That's what one has sev/incident response procedures for.
| Put everyone in the entire management chain on a
| conference call with execs/comms/legal for as long as it
| takes - and make damn sure the line manager is shielding
| the actual engineers from this process so they have time
| to fix the bug.
| Ensorceled wrote:
| > Oh, I see... I just assumed people read tickets and did
| the work and updated the ticket?
|
| There are a LOT of Professional Scrum Masters and Product
| Managers who want to constantly review the state of
| tickets, make update/status comments and communicate simple
| questions and answers via the ticket system.
|
| Did you mean 'x'? Yes, I meant 'x'.
|
| Our slack bot channel exploded when we hired a new Product
| Manager who communicated strictly via ticket updates,
| literally dozens of alerts per day. They got upset when
| they found out every single developer had unsubscribed from
| all the ticket channels because of the noise.
| docandrew wrote:
| You've never wasted a few minutes on whether a ticket was
| "critical" or merely "high?" or truly a blocker?
| robertlagrant wrote:
| > You've never wasted a few minutes on whether a ticket
| was "critical" or merely "high?" or truly a blocker?
|
| Calling "deciding on how to spend your time" a waste of
| time seems a misnomer.
| watwut wrote:
| But ... that person is not deciding how he will spend
| time. He is deciding which labels to put on ticket. What
| he will do is not directly related to that.
| robertlagrant wrote:
| What's a priority but a way to decide what to do next?
| The fact it's stored as a label on a ticket doesn't seem
| particularly relevant.
| watwut wrote:
| It is a way to categorize tickets. It somehow influences
| what is going to be done next, but it is only one of many
| factors.
|
| One project manager in our company started to actually
| use it for prioritization, the higher the priority the
| sooner it was done. Soon after, literally everything
| ended to labeled critical.
| nerdponx wrote:
| People shouldn't be able to label their own
| bugs/features' severity or importance. They should be
| able to label it with severity or importance _to them_ ,
| and the team responsible should be allowed to triage
| accordingly.
| JoeAltmaier wrote:
| Absolute priority quickly becomes washed out - everything
| gets shoved to one end of the range.
|
| A useful priority scheme might be, insert the ticket in
| the list of open tickets by urgency and importance.
| Something like that, that you can actually make arguments
| about and compare.
| ryandrake wrote:
| Almost every software company I've ever worked with had
| this insidious "priority inflation" that couldn't be
| stopped. It works like this:
|
| We start out with some sensible definition of priority
| for bugs: P3 = nice-to-have, P2 = low-priority-but-ship-
| blocking, P1 = emergency-fix-this-now. Bug intake goes on
| for a while under this system. Some bug filers don't feel
| their P3 or P2 bugs are getting worked on, so they
| "promote" those bugs to P2 and P1. That'll show those
| engineers my bug is important! Now we seem to have more
| and more P1 emergencies going on, and the team is
| struggling to just get through those. Nobody knows which
| ones are actual emergencies, and which ones are just
| "somebody being passionate about a bug".
|
| Soon, we get an actual pants-on-fire production
| emergency. This emergency is more urgent than any P1, so
| we call it P0! Now we finally have a way to mark real
| emergencies, because the bug database is now overflowing
| with P1s. Soon people realize they can deem their
| favorite bugs as really-really-important, so they promote
| them to P0. Eventually, the database is now overflowing
| with P0s, and nobody knows what's really urgent. Then
| another real pants-on-fire production emergency
| happens...
| bstpierre wrote:
| I worked at a shop with P0, and then there were too many
| P0 tickets, and then you just worked on whatever the CTO
| told you was the _actual_ highest priority ticket when he
| stopped by your cubicle for a chat.
| plorkyeran wrote:
| The discussion over what priority label to put on a
| ticket has very rarely changed my opinion on what the
| actual importance of the ticket is, and I'm generally
| going to pick what to work on based on that, not based on
| the label.
| theamk wrote:
| If ticket priority does not matter, then why do you care?
| Set them all to single priority and don't think about it.
|
| If priority does matter, then why "waste"? Lets say you
| get rid of tickets.. then your statement becomes:
|
| "You've ever wasted a few minutes on whether a bug you
| found is worth mentioning in release notes? Or if it
| truly should cause revert of deployment?"
|
| When said this way, doesn't seem like "waste" to me,
| rather a regular part of the job. If the person working
| the bug doesn't know how bad it is, then who does?
| swiftcoder wrote:
| > If ticket priority does not matter, then why do you
| care?
|
| Because when you have a ticket priority system, there is
| often someone external who cares deeply about ticket
| priority. And reporting requirements around ticket
| priority. And metrics about ticket priority over time.
|
| If you've never been pulled into a meeting with Comms and
| Legal to discuss retoractively whether a (completed)
| ticket should have been labelled High or Severe... count
| yourself lucky
| commandlinefan wrote:
| > whether a ticket was "critical" or merely "high?" or
| truly a blocker
|
| Wait until they start adding additional categories like
| critical blocker, high blocker, severe blocker,
| exceptionally severe blocker, etc. etc.
| fourseventy wrote:
| Infinity blocker, infinity + 1 blocker
| cratermoon wrote:
| Now apply that category soup to tracking both priority
| and severity.
| nerdponx wrote:
| I certainly have, but I have rarely regretted spending
| the time to prioritize my work before starting my work
| and/or discussing the same with my team. Like pretty much
| all work of all kinds, there is variance in how long it
| takes and how effective the outcome is per person-minute.
| watwut wrote:
| These categories on ticket have little to do with me
| prioritizing my work. There are thousands tickets in each
| of those categories.
|
| >spending the time to prioritize my work before starting
| my work and/or discussing the same with my team
|
| And in the past, I did regretted opening unnecessary
| discussions quite a few times. I learned not to do it,
| because it ended in endless bike shedding or conflicts
| and there were no special gained insights. Turns out, I
| can do trivial decisions by myself.
| nerdponx wrote:
| This seems like a highly dysfunctional state of affairs.
| Maybe I've never worked at an organization big enough to
| suffer from this kind of thing.
| docandrew wrote:
| Exactly, there's a fine line between prioritization and
| bikeshedding.
| steveBK123 wrote:
| Emphatically yes, there's some really broken process out
| there.
|
| I sat on a team with 6+ hours per week of full-team, in a
| room, jira ticket creation/reviewing/sizing/prioritizing.
| So thats 15% overhead right off the top.
|
| This of course was not the only time we spent interacting
| with tickets, as we then had daily standup, random "check-
| ins" from product/management on ticket status, and of
| course actually picking, updating, and closing our own
| tickets throughout the sprint.
|
| Easily spent 30% of our time talking at high level
| management view about doing work rather than just
| technically planning & doing it.
| jameshart wrote:
| I understand developers' complaints about this sort of
| thing and I am as much of a Jira-burnout victim as the
| next coder.
|
| But.
|
| How much time _should_ a team be spending figuring out
| what the right thing to do is? Figuring out if the plan
| is still the right one?
|
| 15% honestly doesn't sound like a number I would
| automatically assume is 'too much' for such activity. I'm
| not sure even 30% sounds like a crazy high number.
| Building the wrong thing is expensive. Building pieces
| that don't fit together is expensive. Avoiding those
| mistakes requires investing time in some sort of planning
| activity.
|
| It doesn't have to be Jira backlog grooming, sure. But it
| has to _happen_.
|
| If the developers aren't spending their time doing this,
| _who is?_
| swiftcoder wrote:
| > Figuring out if the plan is still the right one?
|
| 15% _every week_ is the problem here. If you spend 10% of
| your annual budget on upfront planning and 5% monthly on
| checkins, that 's maybe ok. Putting the whole team in a
| room every week is just going to churn the plan
| constantly - inputs likely aren't changing with that
| frequency, and you aren't going to be able to pull in all
| the other stakeholders that often anyway
| jameshart wrote:
| Sorry, are you suggesting a better way to operate is to
| have the team go off for like a five week offsite to come
| up with a plan for the rest of the year? Then once a
| month, they get a day to figure out if the plan's still
| working?
|
| It's an option, I guess... let us know how it works out
| for you.
| swiftcoder wrote:
| I mean... yeah. That's kind of how a lot of big
| enterprise projects with VP-level visibility get managed
| (I participated in versions of this at both Amazon and
| Facebook)
|
| Obviously you don't need to pull all the junior eng
| offsite for a whole month, but the engineering leads +
| PMs + engineering management end up there. And obviously
| there's also ongoing prioritisation happening between
| leads/PM/management throughout the year - but that
| doesn't require pulling the whole team every week.
| steveBK123 wrote:
| Yeah, I think this level of planning has gotten lost in
| our recent fad of agileness.
|
| Senior management thinks they know where they want to be
| in 3 years, but there is no cascading multi-quarter, let
| alone multi-year planning of the projects & steps to get
| there.
|
| I've even been in orgs where someone senior is trying to
| make very very large org & tech changes, and really can't
| be bothered to put the big building block steps to get
| from here to there. As it turns out, they never get
| "there".
|
| Somehow they know enough to bring in project managers for
| big concrete things like "retire a datacenter" and go all
| out with MS Project, GANTT, etc.
|
| However when it comes to software changes like "split an
| on-prem Java monolith into a fleet of python micro
| services in the cloud" ... it's all iterative vibes the
| whole way.
| jameshart wrote:
| Agileness is many things but I really think we can stop
| thinking of it as a 'recent fad' by now. The manifesto
| was written 22 years ago. It's been the dominant mode of
| engineering organization for over a decade.
| steveBK123 wrote:
| That's a horrible idea for sure, but I'm not sure the
| current model being derided works for all team
| compositions either.
|
| In a 20+ person dev team with a lot of juniors, the team
| is not "coming up with a plan" or "deciding if its still
| working" so much as product/tech lead/a couple seniors
| who have zones of responsibility are handing one down.
| The two hours spent in the room is agile kayfabe.
|
| "Get everyone in a room and hash it out for 2 hours" is
| maybe a model that works at team size of 5, senior,
| empowered engineers, but it is not something that works
| at large scales.
| crazygringo wrote:
| > _Putting the whole team in a room every week is just
| going to churn the plan constantly_
|
| Yes, that's the point, that after each week (or two) of
| work, we've learned more and the plan already is outdated
| and needs to change.
|
| > _inputs likely aren 't changing with that frequency_
|
| In my experience, they _absolutely are_ unless you 're
| building the simplest CRUD app that's identical to one
| you've built before. The inputs are less often changes
| from external stakeholders, and more often tasks that are
| turning out to be more difficult than hoped.
|
| > _and you aren 't going to be able to pull in all the
| other stakeholders that often anyway_
|
| Of course you are. It's the PM's job to gather the new
| inputs, go check in with relevant stakeholders (takes a
| day or two at most), update or re-confirm their
| priorities, and then make the updated decisions for the
| next sprint.
|
| In my experience, 15% of time spent each week on planning
| is about right. It doesn't maximize the productivity of
| each person coding, but it hugely maximizes the
| productivity of the whole team in delivering a valuable
| end result.
| plorkyeran wrote:
| My experience with weekly ticket grooming is that most of
| the time we spent 1-2 hours talking about the exact same
| tickets we talked about last week and left everything in
| the exact same order as it was when we started. When
| working on quarter+ long projects there just wasn't
| anything that changed week-to-week, and when things did
| change the actual planning to adapt to that was done
| immediately, not in the weekly meetings.
| steveBK123 wrote:
| What was great with my ticket grooming bi-weeklies was
| that despite having 20 engineers in a room, we were
| strongly admonished from going into technical details of
| implementation in the room. "Take those offline. But
| please put a size on the ticket, thank you."
|
| What else do you want us to do for 4-6 hours/week? Write
| poetry?
|
| Eventually every ticket just gets sized "medium-big", and
| people keep their heads down with mouths closed.
| ResearchCode wrote:
| I don't think that's the case for most of the substantial
| software projects. The plan for the Linux kernel doesn't
| change each week (do they have "PMs"?).
|
| 15% seems very excessive. Almost a whole day a week and
| two days lost of deep work. Try to aim for 1.5%. Do as
| much of the planning as possible without a meeting.
| steveBK123 wrote:
| Exactly. A real product driven company with a mature
| product isn't interacting with customers frequently
| enough to upend their plans every 1-2 weeks.
|
| How do people think Apple develops completely new product
| lines like the iPhone, iPad, watch, etc.
|
| There's a lot more up front planning (and yes .. of
| course, course corrections) than a lot of agile advocates
| want to admit.
|
| Most agile hyped up senior management I've met just use
| it as an excuse to be derelict in their ability to plan
| anything.
| crazygringo wrote:
| > _isn 't interacting with customers frequently enough to
| upend their plans every 1-2 weeks._
|
| As I said, re-planning is more often than not needed
| because of _technical_ challenges developers are running
| into. If one person is going to take 4 weeks to deliver
| something instead of the expected 2 days, lots of things
| may have to be rejiggered.
|
| But also, yes even "real product driven company with a
| mature products" are changing plans every 1-2 weeks.
| Because each new incremental feature is a little project
| of its own. I never said plans get "upended" but they
| absolutely need to get re-adjusted ever 1-2 weeks based
| on _both_ dev input and product /user reaction.
|
| If you want to talk about the iPhone, just look up the
| history of how the software keyboard was developed. Talk
| about rapid prototyping and upending plans!
| jameshart wrote:
| 1.5% of a workweek is 36 minutes.
|
| I don't know how you can get a team of developers to
| productively spend 39 hours and 24 minutes of keyboard
| time productively coding in the same direction with only
| 36 minutes of discussion.
| steveBK123 wrote:
| So, in my example, we were having 2-3x/week 2-hour, full
| dev staff meetings.. without product in the room. He was
| a very busy man and could only grace us with his presence
| for 30 min every 2 weeks to basically sort the tickets we
| had spent 12 hours putting together and decide which he
| actually cared about.
|
| Much could be accomplished more efficiently by getting
| product, management, and 1-2 seniors in a room for 30min
| to actually decide what/if plans have changed & cascade
| the changes accordingly.
|
| 99 times out of 100, the plan didn't change because
| something raised from the bottom, but because management
| has changed direction or users have asked for something
| new. Why subject 95% of the team to hour long monologues?
| [deleted]
| [deleted]
| marcosdumay wrote:
| > How much time should a team be spending figuring out
| what the right thing to do is? Figuring out if the plan
| is still the right one?
|
| Keep in mind that in most "jira-oriented" places (or
| probably all of them), that task isn't attributed to
| developers at all.
|
| If you are doing this and development, like a healthy
| place, yes, 30% of the time evaluating your work sounds
| sane. But that evaluation time must not be interleaved
| with development time at all. Any interleaving will
| destroy the value of both tasks.
| jameshart wrote:
| Stipulated: many companies suck at engineering
| management.
|
| But in companies that are _good_ at engineering
| management, you will often find:
|
| - weekly planning sessions
|
| - daily standups
|
| - work ticketing and backlog systems (sometimes Atlassian
| ones!)
|
| - prioritization discussions
|
| So I would suggest that anyone who assumes that those
| activities correlate with bad engineering management, is
| falling into a base rate fallacy.
|
| P(is badly managed | Jira) is high, but that's because
| P(is badly managed | tech company) is high.
| mgkimsal wrote:
| > Building the wrong thing is expensive. Building pieces
| that don't fit together is expensive. Avoiding those
| mistakes requires investing time in some sort of planning
| activity.
|
| The promise of "agile" is, IIRC, faster turnaround and
| iterative development. Yes, the 'wrong' thing is
| expensive. Getting something basic in someone's hands in
| 2-3 days to get some feedback is _usually_ more
| productive than days of figma then 'sign off' then work
| work work then putting it in hands and getting back "this
| is wrong" (missing data, etc). Sometimes those things can
| be found in 'design-only' sessions, but I've _rarely_
| seen it happen where lots is found there, then things are
| implemented perfectly afterwards not requiring any
| further changes.
|
| Much depends on the size/scope of the work, and I don't
| think there's one-size that fits all, but the
| ticketization of work process as teams grow pushes
| towards "one true way", which then seems to paper over a
| lot of cracks that don't easily show up in burndown
| charts.
|
| That 15 or 30% _might_ be the time ultimately taken on
| thinking /planning/etc of a specific issue, but too often
| it seems there's an idea of doing more up front "gets it
| done" and the notion of fast feedback/iteration cycles is
| glossed over, and you're expected to "get it done" - "all
| the planning was already done".
|
| When doing dev-type work, I _always_ end up needing to
| iterate with endusers /stakeholders, and there's little
| 'up front' that could have been planned to avoid some of
| that. It may be the nature of the people/teams I've
| worked with, though.
| steveBK123 wrote:
| Yeah and the larger issue - putting 20 people in a room
| for 2 hours violates like every single management /
| efficiency / socio-political recommendation in the book.
|
| The more people in the room, the fewer participate, the
| fewer decisions get made, the more gets punted to the
| next time 20 people are in the room again in 3 days.
| jameshart wrote:
| > The promise of "agile" is, IIRC, faster turnaround and
| iterative development.
|
| The promise of agile is _working software_.
|
| Iterative development is a how, not a what.
| steveBK123 wrote:
| People should absolutely be planning their work. Measure
| twice, cut once. But then again, isn't agile supposed to
| be iterative? Measure, cut, measure, cut, measure, cut..
| repeat?
|
| How much value do you get from putting 20 engineers in a
| conference room for 2 hours, 2-3 times per week? What if
| this is mostly just a head strong manager who enjoy
| monologuing his captive audience team?
|
| Note I said "spent 30% of our time talking at high level
| management view about doing work rather than just
| technically planning & doing it" This doesn't really help
| prevent building things that don't fit together at all.
| It barely allows you to surface technical dependencies
| and order of operations.
| maerF0x0 wrote:
| How long do your legs need to be? Long enough to reach the
| floor.
|
| How much Jira (or other tool) is needed is a very subjective
| thing, but when you focus on the outcomes it can become clear
| if you need more or less.
|
| Does any of your manager, Product Manager, Project Manager,
| skip level, or teammates create unneeded communication
| overhead asking what the status of something is and when it
| will be done? A planning tool should communicate that.
|
| Are deadlines being missed or visibility into what is
| actually being done missing? Planning tools should help with
| estimation and revealing how much complex work is being done.
|
| In a lot of ways these tools are not going to make the work
| faster, but instead make it so that the human side is
| appeased. It reduces anxiety of managers, it creates an
| understandable evidence of work (most non-technical folks
| cannot tell the difference between a good and great
| implementation just by observing the app, but they can
| understand a ticket that explains a refactor). It drives
| alignment, communication, and buy in.
|
| The fastest a developer can go is alone in a dark room with
| no interruptions. But that doesn't scale. Even if that
| engineer is a 10x engineer, you still need a different system
| when you want 11x development. That's when planning,
| communication, coordination, allocation etc. all come into
| play.
| nico wrote:
| Everyone is different. The key is not forcing people into your
| own worldview.
|
| Some people do better with documentation or tickets or code or
| meetings.
|
| The point is that forcing people to do shit they don't want to
| do will backfire and make teams unhappy and unproductive.
| jltsiren wrote:
| Everyone is different, but it doesn't matter that much.
|
| When you have a small team, you can often organize the work
| the way people prefer. Then you'll find that people who can
| be incredibly productive under ideal circumstances are
| actually quite common.
|
| But as the organization grows, you have to focus more on the
| process and the structure. Individual productivity doesn't
| matter if you can't channel that productivity to advance the
| organization's goals. You rely increasingly on people who can
| work productively within the system. People who thrive in a
| wide range of environments, even when they would prefer
| having things organized in a different way.
| nico wrote:
| Why does the organization need to grow?
| jrussino wrote:
| I recently heard a quote that resonated with me: "If you want
| to go fast, go alone. If you want to go far, go together". I
| wonder if someone who treats these tasks as "non-work" is
| thinking of themselves as being more productive because they go
| faster than the folks around them, not considering that these
| other tasks that slow them down individually also help the team
| go farther in the long run...
| watwut wrote:
| Unless of course, they are not helping the team at all.
| Unless they are busywork we go through without ever looking
| at again or using it practically. Unless they are made to
| avoid making decision and then to avoid it again.
|
| The company I work for have quite a lot of all hands
| presentations with content relevant to like ... 5 people.
| While everyone else nods, sleeps, reads reddit, zooms out
| daydreaming. We have diagrams that have nothing to do with
| anything, but make manager feel like she is controlling
| something.
|
| We do not spend much time on ticked management tho. Which an
| argument against that idea too - you can in fact have
| functional ticket management without everyone spending too
| much time on it. But, I did seen overly complicated systems
| in the past that required constant fiddling.
| danaris wrote:
| It's always a balance. There is no universally-correct
| amount (or types) of meta-work to make a team function
| optimally.
|
| For some teams, especially very small ones (and most
| especially if they're all _volunteers_ ), adding
| significant amounts of bookkeeping to their tasks is likely
| to be much more trouble than it's worth. (Though, again,
| even for some _solo_ developers, the bookkeeping can be
| very valuable--it 's all about the specifics of the
| projects and the ways different people operate.)
|
| For other teams, _not_ having the extra bookkeeping will
| mean that the people struggle to keep their tasks straight,
| or get abused by their managers, or have a variety of other
| problems.
|
| The most important thing is to be reflecting on your and
| your team's work and processes, and being open to changes
| that might improve them.
| apozem wrote:
| Yeah, in my experience writing complete tickets forces people
| to actually think through designs and trade-offs. It also has
| the nice benefit of exposing their thinking to others in the
| organization, who can weigh in and go, "Oh, if you're doing
| _that_ , we have to do _this_ on our project. "
| steveBK123 wrote:
| It really depends on if tickets are being written as an input
| to the work product, or as an agile mandated box ticking
| exercise.
|
| Do you spend more time wrangling over the ticket content or
| the format? Do you spend more time discussing context &
| requirements, or story points? Etc
| anonytrary wrote:
| Engineer who implements correct, comprehensible code but
| doesn't manage ticket statuses is more valuable than one who
| manages ticket statuses but scatters the codebase with
| technical debt and confusing abstractions/code. If "better
| communication" means spending an extra 10 hours with the latter
| dev to correct/re-teach them, then yes, communication is the
| problem. The most time I've lost at work is correcting/teaching
| engineers who eventually got let go due to low performance.
| doesnt_know wrote:
| I don't really think the first part of your comment is true,
| at least not in my experience. All other stakeholders would
| prefer someone that updates their tickets and communicates
| what they are doing effectively, even if they produce
| absolute garbage, bug ridden software.
|
| I've personally only ever seen someone removed from a team
| for having poor technical skills once and it was under pretty
| extreme circumstances. While I've seen many good (from a
| technical perspective) developers removed because they
| thought they were somehow above doing the everyday "busy
| work" like ticket management.
|
| Unless you work alone, then refusing to do non-technical work
| is just saying you're going to let the rest of the team do
| it. You're much more likely to be removed or have your
| contract ended if the team doesn't want to work with you.
| NikolaNovak wrote:
| FWIW :)
|
| I used to _despise_ the incredible amount of time we could
| spend on a single powerpoint slide sometimes.
|
| Then one day when going over same slide for the 5th time with
| my boss and mentor, I realized:
|
| * This slide will be seen by a person in power
|
| * they will make a decision based upon that slide
|
| * I would _like_ to spend 3 hours explaining them the
| intricacies of my project /architecture/problem/whatever
|
| * But they have 10/100/1000 other projects, and they have
| 20/10/5/1 minute to devote to me before they make a decision
|
| * A slide or set of slides might therefore have an impact
| across 1/10/100 people over week/month/years due to a decision
| based on a slide or set of slides
|
| * therefore, it can at times be rationally logical to spend a
| lot of time word-smithing a slide in order to help the right
| decision
|
| As programmers, we understand that we might spend
| 10min/hour/days/weeks on a small but crucial piece of code,
| because we need the computer to understand it and do the
| _exactly right_ thing in a complicated scenario; and we do not
| consider it a waste of time (though our management might! It 's
| a curiously symmetrical situation :-)
|
| Sometimes, slides are exactly that, but for people - distilled
| information to enable executive stakeholder to do the correct
| thing.
|
| Same with other items - diagrams? They can be phenomenally
| useful! A good diagram can spread understanding of goal and
| ensure we all build the right thing. Bad diagram can set 100
| smart people on divergent paths!
| cratermoon wrote:
| Yes but I've also been buried in presentations, diagrams, and
| ticket management that _don 't_ contribute to communication.
| That's doubly wasteful because not only is time wasted making
| all these artifacts, but even when produced they still don't
| improve understanding. Might as well have a chatbot write them,
| they couldn't be worse. Ticket management fails to keep anyone
| updated when it's just a performative way to make managers and
| execs believe they are seeing progress when in fact the ticket
| board is a fiction unrelated to real effort.
| strangattractor wrote:
| The only 10X engineers I have ever worked with were the ones
| that helped get 2X out of the five normally 1X engineers they
| worked with.
| treeman79 wrote:
| Had many times where I saved a company months of work by
| forcing a meeting to lock in UX requirements. Basically go
| through screen to screen on a whiteboard what should happen.
|
| This almost always leads to major changes to the whiteboard
| during the meeting.
|
| Had many times were I couldn't get company to do this exercise.
| First time leadership sees UX is on completed project.
|
| Team then spends months rewriting application. Everyone
| generally pissed.
| safety1st wrote:
| Yeah that was an interesting read. I like the concept of a -10x
| engineer because they definitely exist (in my mind it is
| someone whose work moves you farther away from the project
| goals, rather than closer to them). But a lot of the bullets
| sounded like stuff bad managers do, not bad engineers.
|
| Off the top of my head these are the most common two "negative
| engineer" behaviors I have seen
|
| 1) Biggest one: an engineer who is not experienced at
| architecting complex systems, goes and architects one when
| complexity was not required in the first place. This is the key
| to never shipping and destroying entire companies.
|
| 2) Close runner up: an engineer who writes code that is
| inscrutable and therefore unmaintainable (always by others,
| often by themselves as well). This is the key to your product
| dying a slow death over several years.
|
| There are negative engineers doing this stuff ALL. THE. TIME.
| EVERYWHERE. Despite unquantifiable volumes of both ink and
| blood spilled trying to prevent them.
| donkeyd wrote:
| I had a -10x engineer in my team. They refused to test their
| own work, because that was the tester's job. They sometimes
| implemented a feature in the wrong place, both technically
| and functionally, requiring a complete rewrite (and removing
| code, roll-back was not an option in this tool). They started
| using float in HTML while we used grid, this caused stuff to
| be on top of each other.
|
| Unfortunately, this guy played management in a way that
| caused him to keep getting away with the behavior. Awful
| person to work with!
| chinchilla2020 wrote:
| We hire for case 2. The hiring process requires deep,
| esoteric knowledge on sub-optimal data structures and
| algorithms.
|
| A frontend developer that uses lots of bitwise operations and
| tricky mathematical algorithms to display CRUD is simply a
| developer who studied those things.
| Herval_freire wrote:
| >Yeah that was an interesting read. I like the concept of a
| -10x engineer because they definitely exist
|
| I don't believe 10x engineers actually exist. Maybe 1.5x, 2x,
| or 3x engineers exist at most. 10x is a huge exaggeration of
| human capability.
|
| Get this, say a project takes a year to complete. The concept
| is saying a 10x engineer can do this in about month. If such
| a person exists it will be so rare I estimate that most
| people haven't ever encountered an actual "10x" engineer.
| Even a 3x engineer is super rare. I can see something like 2x
| happening where a project that takes a year is done in 6
| months. That is rare but plausible.
|
| You also might get a lead who can ramp up the effectiveness
| of an entire team by say 3x at most. If the size of the team
| was N, then it's N*3X. If N is like 4 then it's a 12x
| increase. This is the closest thing to an actual 10x
| engineer. But it's not actually a 10x engineer here it's just
| better management.
| 908B64B197 wrote:
| > I don't believe 10x engineers actually exist. Maybe 1.5x,
| 2x, or 3x engineers exist at most. 10x is a huge
| exaggeration of human capability.
|
| I think the reason so many people have doubts on the
| existence of 10x is that they might have never encountered
| one.
|
| I recall a story someone told me a while ago. Software
| business that did local CoL/prevailing wages. Hired an
| intern one summer that was just running around in circles
| around the other, more senior devs. Useless to say they
| loved him and the next summer they tried to get him back,
| even offering a signing bonus for an internship (something
| they considered unheard of) but he was already at a large
| search engine company down in the Bay. You can guess the
| comp was probably already 3x what his previous job was
| offering. Of course, he wouldn't return.
|
| There's a whole class of engineers were completely
| invisible to most companies, even if they are in the same
| "local market" [0][1] (Some use the term "dark matter devs"
| but I know it has another meaning [2]). These guys tend to
| fly under the radar quite a bit. If you are in a tier 2
| market or company, your chances of attracting one are close
| to nil. Because they are extremely valuable, they don't
| interview a lot and tend to hop between companies where
| they know people (or get fast tracked internally). When
| hiring is red hot, they might completely disappear from the
| hiring pool by junior year.
|
| > Get this, say a project takes a year to complete. The
| concept is saying a 10x engineer can do this in about
| month. If such a person exists it will be so rare I
| estimate that most people haven't ever encountered an
| actual "10x" engineer. Even a 3x engineer is super rare. I
| can see something like 2x happening where a project that
| takes a year is done in 6 months. That is rare but
| plausible.
|
| That's thinking in terms of bricklaying. 10x, like Carmack
| or Woz for example, bring completely new ideas and paradigm
| shifts. Think of the engineering happening at Xerox PARC
| for instance.
|
| [0] https://blog.pragmaticengineer.com/software-
| engineering-sala...
|
| [1] http://danluu.com/bimodal-compensation/
|
| [2] https://www.hanselman.com/blog/dark-matter-developers-
| the-un...
| hcs wrote:
| Negative 10x
| Herval_freire wrote:
| Oh man. My eyes just skipped over that negative sign
| every time. Now it makes sense. I thought the article was
| sarcastic. I'm blind.
| nrclark wrote:
| a 10x engineer might not exist. A -10x engineer (or more
| accurately: a 1/10x engineer) definitely does.
|
| This article isn't about engineers that make your team
| better; it's about engineers that make your team worse.
| rzzzt wrote:
| The distinction is important: someone else already wrote
| that the -10x person will move you further away from the
| goalpost, while the 10-1x counterpart is still moving
| towards it, only slower.
| nrclark wrote:
| That's a good point. If your team has an 0.1x engineer,
| you'll still get to your goal eventually. If you have a
| -1x engineer, you might be going in the wrong direction
| to ever finish your project.
| JohnFen wrote:
| > a 10x engineer might not exist
|
| 10x engineers do exist, but they're vanishingly rare. I
| actually met one once. He eventually burnt out and left
| the industry permanently.
| debatem1 wrote:
| > Get this, say a project takes a year to complete. The
| concept is saying a 10x engineer can do this in about
| month.
|
| You've really never met this person? Feels like more or
| less everyone with real expertise should be able to do this
| in the right job.
| lelanthran wrote:
| > You've really never met this person?
|
| Nope. I've never met anyone who can complete in a month
| what it takes an average coder a year to complete.
|
| Neither have you.
| monktastic1 wrote:
| In my time at Google, I saw numerous projects completed
| that a whole army of me could _never_ complete (according
| to the required standards). There are many such problems
| where throwing more bodies at it won 't help; genuine
| insight is necessary. I'm surprised you haven't
| encountered this.
| mr_00ff00 wrote:
| TempleOS anyone?
| sigstoat wrote:
| > Nope. I've never met anyone who can complete in a month
| what it takes an average coder a year to complete.
|
| i've built in two weeks something that took another guy 5
| years to not even quite finish. with better performance,
| reliability and extensibility across the board.
|
| that's a factor of 130x (or more!). how do you want to
| divide that up between the two of us? if he's 0.01x, how
| rare must he be for the "average" to still be sitting at
| 1x?
| Herval_freire wrote:
| Every competent and qualified engineer should be able to
| do the job of 10 competent and qualified engineers?
|
| The statement that every engineer can be a 10x engineer
| is recursively paradoxical. If a 10x engineer existed, in
| my mind, he would immediately be able to identify this
| logical error.
| intelVISA wrote:
| In some domains and markets they're probably a genuine
| myth.
|
| Remember, for every Bellard, Carmack or jart: there's at
| least 100,000 glue engineers who are just trying to cash
| in some easy VC checks - can't blame them at all.
| tijsvd wrote:
| > Get this, say a project takes a year to complete. The
| concept is saying a 10x engineer can do this in about
| month.
|
| The true 10x engineer looks at the project, sees the
| inherent needless complexity, goes back to the sponsor and
| uses his business knowledge to renegotiate the specs.
| Leading to a reduced scope with 98% of the business value
| and 10% of the work.
| The_Colonel wrote:
| > You also might get a lead who can ramp up the
| effectiveness of an entire team by say 3x at most. If the
| size of the team was N, then it's N*3X. If N is like 4 then
| it's a 12x increase. This is the closest thing to an actual
| 10x engineer. But it's not actually a 10x engineer here
| it's just better management.
|
| All of that are arbitrary numbers. 10 is arbitrary and not
| actually measurable, but your 3, 4 are as well.
|
| But I think you're on the right track with this thinking.
| "10x engineer" does not make things 10 times as fast as
| "1x" engineer does, they do qualitatively different things
|
| Take an example of an engineer who sees through the
| bullshit of a "cloud architect" who specifies a complicated
| architecture with novel technologies to pad his resume.
| Cutting down on this can easily save the project / deliver
| much faster.
|
| This is kind of an interesting view - 10x engineer does not
| make projects run 10x faster, but they prevent mistakes
| which would slow down the project by factor of 10.
| svachalek wrote:
| These are so common. The problem engineer will tend to be
| seen as a genius with inadequate help, the only one who can
| save us (from the pit he dug for us).
| Viliam1234 wrote:
| The "genius" who saves the company from the problems he
| created, is not the apex negative engineer. The time he
| spends fixing his own mistakes is the time he does not
| spend creating new ones. Sometimes his creativity will be
| limited to a single project.
|
| There is also the type of "genius" who creates an
| overcomplicated framework as a foundation for a new
| project, and then leaves the implementation details to
| lesser minds trying to understand his work, while he moves
| to start another new project. He is always too busy working
| on a new project, doesn't have time to answer questions
| about the old ones. (The problem is sometimes solved by
| gradually removing his code. In extreme case, the library
| remains included, to avoid a political conflict, but the
| code is actually never called.)
| pcthrowaway wrote:
| > In extreme case, the library remains included, to avoid
| a political conflict, but the code is actually never
| called
|
| Ah yes, if the wrong people become aware that the code is
| never called, better to claim that it happened as too
| many people had their hand in the pot, and hey, the code
| is still working, and the tests are passing, so you
| didn't realize anything was wrong, rather than ruffle
| feathers and say you didn't want to touch the "genius"
| code because it was stuck up its own ass.
| mgkimsal wrote:
| Holy tamole.
|
| Had worked someplace for a short stint. There was a guy
| who'd started a couple months before I did. His work was
| 'revolutionary' and 'groundbreaking' - he'd been trying to
| build some sort of AOP-style PHP system - PHP4, mind you -
| without any extensions or internals work. It was just
| 'program this way' - undocumented patterns that encouraged
| copy/paste to half-way almost get you something usable
| (except, not really). "Build a form to take a few fields
| input and store in a database" example took days to
| develop, because... he was just winging it. Session
| management? nope - we'll need to roll our own, and that'll
| take a few weeks.
|
| About half the team (20ish folks) were enraptured by this
| guy. Someone rambled about great this guy was, said
| something along the lines of "you know those sorts of
| geniuses that are so far ahead of everyone else that they
| can't even explain things, and no one else can quite
| understand it? that's where we're at, and it's just so
| awesome - I can't wait to learn more!"
|
| This guy saying that was, at the time, like... the #2 guy
| on the team, had been there for years, and was the defacto
| 'team lead' for that work, and he was taken in by a
| huckster. The aop guy was there for about 10 months, then
| left abruptly - left on a friday, sent an email on monday
| with "i resign, i got another job". somehow, some folks
| were "shocked" at his "unprofessionalism". The entire
| tenure had been unprofessional, but few cared to label it
| that.
|
| You're so good and smart that you built something we all
| need to use, but you can't explain it (let alone why it's
| good/better), everyone else plainly admits they don't
| understand much about it, and use the lack of understanding
| as evidence that they're so bad this _must_ be genius-level
| work. Insane...
| yamtaddle wrote:
| I remember reading a blog post from a certain project
| management software startup bragging about their genius
| lead engineer who created this wonderful NIH frontend
| framework for them, how it worked, et c.
|
| Having used the product (which would not-infrequently
| manage to make keyboard input lag by _full seconds_ on
| strong hardware, ate hundreds of megabytes of ram and
| tons of processor cycles while idle--even worse than your
| average webshit "app") and putting 2 and 2 together, I'm
| pretty sure I could have written a list of things they'd
| failed to take into account, and reasons the results were
| so poor. It was a fun read thanks to all the details,
| like "oh, _that 's_ why this is so awful, I see exactly
| what's wrong now".
| hsbauauvhabzb wrote:
| I think referring to office 365 as a 'software startup'
| is a fairly long stretch, so I may have come to an
| incorrect conclusion but the rest is a fairly accurate
| description of o365 in my experience.
| yamtaddle wrote:
| Asana.
|
| [EDIT] Though to be fair--and why I hesitated to name
| them--I haven't used their product in four or five years,
| and it may be much better now. Looks like the framework
| they created is called Luna.
| cratermoon wrote:
| > "you know those sorts of geniuses that are so far ahead
| of everyone else that they can't even explain things, and
| no one else can quite understand it?"
|
| Richard Feynman was certainly a genius and he was well-
| known for his ability to explain complex topics in ways
| laypeople could grasp.
| denton-scratch wrote:
| I don't believe a fellow is clever, unless he can explain
| his clever thoughts clearly. Feynman was seriously
| clever.
| mynameisvlad wrote:
| Yep, someone smart enough to come up with something
| should also be smart enough to be able to break down and
| explain what he came up with.
| digging wrote:
| Totally agreed. I don't trust smart people who can't
| explain their ideas. It's not that I don't think they're
| right, it's that I don't think it's a good business idea
| to operate on faith. But also, being able to break a
| concept down increases the smart person's level of
| comprehension of their ideas - it's not only proof, it
| has tangible benefit.
| arcanemachiner wrote:
| "If you can't explain it to a six year old, you don't
| understand it yourself." - Albert Einstein*
|
| *I'm skeptical of any quote attributed to Einstein, but
| Goodreads said it's by him.
| elcritch wrote:
| Pretty sure that one is from Feynman.
| shagie wrote:
| From a bit ago:
|
| We fired our top talent. Best decision we ever made. -
| https://www.freecodecamp.org/news/we-fired-our-top-talent-
| be... ( https://news.ycombinator.com/item?id=15474893 125
| comments; https://news.ycombinator.com/item?id=32211953 30
| comments)
|
| > "You will never be able to understand any of what I've
| created. I am Albert F**ing Einstein and you are all
| monkeys scrabbling in the dirt."
|
| > And so our resident genius, our Dr. Jekyll, explosively
| completed his transformation into Mr. Hyde.
|
| > He declared this in front of the product design team,
| developers, management, and pre-launch customers. One of
| our project sponsors had the temerity to ask when the
| problem crippling our product would be fixed.
|
| And then follow up:
|
| A team reborn after the fiery departure of its misanthropic
| guru - https://blog.solha.co/life-after-rick-our-team-
| reborn-after-...
| oblio wrote:
| https://workchronicles.com/prevention-and-cure/
| JohnMakin wrote:
| Thanks for reposting this. Sounds so eerily similar to my
| last principal that I wonder if it's the same guy,
| although I'm sure this is a common phenomenon.
| ARandomerDude wrote:
| Great read, thanks for (re)sharing.
|
| Amazing how much of this resonates with behaviors I've
| seen over the past few years.
| passwordoops wrote:
| And it's funny how wherever things finally come to a head
| and you part ways to much hand-wringing and doom and gloom
| scenarios... Lo and behold, turns out the new guy can make
| it work just fine. In fact he's refactoring out the
| unnecessary complexity as we speak
| digging wrote:
| I find #2 is fairly easy for me to avoid by focusing on code
| quality and readability. But working in front-end, I'm always
| afraid of doing #1. The paradigms shift so quickly I never
| feel _sure_ I 'm using the right patterns.
|
| Time has proven that generally I'm close enough, but I still
| fear it.
| babyshake wrote:
| It's all too common for engineers to encourage (or to
| "request changes" and block a pull request from merging)
| changes to some code to eke out a bit of non-perceptible
| performance improvement by rewriting code in a way that makes
| it more difficult to understand or more complex. There are
| certainly situations where every ounce of performance gain is
| worth it, but no, your web app serving 100 DAUs is not it.
| austin-cheney wrote:
| Super subjective. The most common thing I see is developers
| compensating for this by never writing original code and then
| demonizing others who do when they cannot read it. By
| original code I don't mean config files or glue for
| frameworks.
| whateveracct wrote:
| Yep I've seen seniors/principals come in and steamroll
| people trying to do FP by claiming that it was inscrutable
| and irresponsible. Sometimes even going up the chain to
| cause shake-up without the team's input. Even though said
| FP was in production, working with a low bug rate, and the
| entire team was fine with it. And I've seen this happen at
| multiple companies.
|
| I've come to think it's the biggest existential risk to
| doing Haskell in industry - it's red meat to org-chart
| climbing sharks. And the people who tend to be willing to
| learn and do FP in prod tend to not be politically-minded
| (usually due to strong principles and values), making them
| even weaker to these attacks.
| eecc wrote:
| Heh, I was once walked through a live "code review" where
| all my code that used Java steam maps were replaced by
| this one dude with for loops in private methods. What a
| dress-down... pff, the project was canned a few months
| after I left. But I'm a consultant, no long term
| investments
| Starlord2048 wrote:
| It seems as though the main issue here is not with FP
| itself, but with the politics and power dynamics within
| organizations.
| whateveracct wrote:
| Oh definitely, but sadly I think the culture and people
| involved in FP tend to be susceptible to politics. But I
| am in no way _blaming_ that or acting like FP should
| change. Those same cultures, values, and people are what
| make the various FP languages and communities out there
| great.
| vbezhenar wrote:
| I am that guy. Because you'll leave and there will be no
| one brave enough to support and expand this code. And so
| it'll get rewritten from the scratch. Why not write it in
| a maintainable way from the start.
|
| A significant part of choosing a technology is economics
| of people available to hire. Who can work with that
| technology 5 years later, when original authors will be
| long gone.
| Xelynega wrote:
| Isn't that kind of self-fulfilling?
|
| Only choose technologies that are popular for production
| stacks -> more people using those technologies
| professionally(implying less using others) -> only choose
| popular technologies -> etc.
|
| From a "making a quality product" standpoint it would
| make more sense to me to choose the technology
| intelligently according to the needs of the product.
| Anything less is just a business mythology about trying
| to deliver a lower quality product for a lower cost.
| oblio wrote:
| > From a "making a quality product" standpoint it would
| make more sense to me to choose the technology
| intelligently according to the needs of the product.
| Anything less is just a business mythology about trying
| to deliver a lower quality product for a lower cost.
|
| The "needs of product" should include "long term
| maintenance cost".
| krooj wrote:
| You're gonna take heat for that position, but I'd support
| you, having been in the same position. Came to a team in
| a company that had a handful of services where folks had
| been "doing things" in an FP manner where it was entirely
| inappropriate (CRUD app, without going into details). The
| had wonderfully illegible, but functional, code that was
| lacking required basics like transaction management, yet
| were befuddled as to why certain integration tests or
| deployments were behaving unpredictably. Similar to your
| situation, the original decision makers were long gone by
| the time I arrived.
|
| It never ceases to amaze me how far you can get with
| going back to basics of solid software engineering and
| the manifestations of those basics, mainly:
|
| 1. OOP to prove that you have a good grasp of the domain
| and problem space. Show me you know what's actually
| happening through code and tests. 2. Build relations -
| it's far, far, FAR easier to go from BCNF/3NF to a
| denormalized state than the opposite when you've got lots
| of data. It's also far easier to perform operations on
| that normalized state with certainty that your change
| will fucking work. 3. Focus on APIs first. Whatever the
| bounded context, focus on the APIs and how they'll be
| consumed.
| whateveracct wrote:
| The only reason the 10+ authors (all plenty skilled in
| Haskell either before joining or due to working on the
| project) were all gone is because said senior came in and
| pushed them out. As I said, the team was fully
| functional, in production, low bug rate, generally happy.
|
| Is it really cheaper to rewrite an entire working system
| (that took a year+ to build in the first place) than to
| just learn something new? I have learned a new language
| in order to inherit a working, hardened, well-made system
| before. But I am finding for certain senior engineers,
| the answer to "can I learn a new language" is a
| resounding no. The cost is infinite, so of course it's
| cheaper to rewrite. Plus they are incentivized to rewrite
| thanks to political reasons (i.e. it's a great way to get
| promoted).
|
| The last time it happened, I was lucky enough to be
| accidentally shielded from accountability due to the
| organizational quagmire that resulted from the team
| blowing up. I basically got to do nothing for a year and
| make $200k. And I got to be less than useful to the
| principal who made the powerplay (not -10x level but I
| did get to spend time maintaining the existing FP system
| due to it having a single production consumer left). That
| dude did not like that I never turned my camera on. My
| manager also seemed pretty checked-out, so that was extra
| buffer.
|
| So to summarize, I'll say that it's easy to have be
| prescient when you make self-fulfilling prophecies.
| That's one skill I've learned from senior management over
| the years.
| lelanthran wrote:
| > The only reason the 10+ authors (all plenty skilled in
| Haskell either before joining or due to working on the
| project) were all gone is because said senior came in and
| pushed them out.
|
| Yeah, but if the stack was something common then it
| _still_ wouldn 't be as big a problem.
| whateveracct wrote:
| I think you're missing my main point which is that _it
| didn 't happen_. The project was successful and chugging
| along.
|
| It was only when a drive-by principal engineer got wind
| of it that there were problems. "We don't use Haskell
| here" was literally the only argument for rewriting it.
| Nobody left before then. We were hiring people fine. The
| problems you are FUDing around didn't exist.
|
| In fact, the rewrite was so slow and off-target that I
| had to maintain the Haskell project through a peak season
| with a skeleton crew of two other people who didn't
| leave. And we didn't even have an outage - I didn't even
| get paged! The project got to make the company millions
| of dollars yet again.
|
| When the rewrite finally started to form, it actually had
| significantly less functionality than the Haskell
| implementation. The internal users complained so much
| about that. And it took just as long to create. What a
| failure that rewrite was.
|
| In the end, it was the attitude you are espousing that
| killed the project, not anything technical or
| hiring-/team-building-wise. It was literally just an
| opinion not to use Haskell by a guy who couldn't be
| bothered for the life of him to try to understand it.
| jay_kyburz wrote:
| Now, every time you hire an engineer they need to spend
| weeks or months learning Haskell on top of everything
| else. It now costs the business an extra 50K every time
| you get a new developer.
|
| I like Google's strategy of having the simplest language
| that anybody can pickup as fast as possible. Go.
| whateveracct wrote:
| There are more costs than onboarding costs.
|
| Also it's not hard to hire Haskellers or Haskell-adjacent
| devs. Haskell in fact makes you stand out. Those sorts of
| people don't need months. I've seen people new to Haskell
| make their first commits within a week. And they weren't
| geniuses or anything. But they also didn't have an
| attitude about it.
| austin-cheney wrote:
| Uugggghhh... "maintainable way" is again super
| subjective. Normally when people say that what they
| really mean is in a way that fits a pattern familiar to
| them.
|
| If software stopped pandering and coddling developers who
| cannot be bothered to read code we would not need
| conversations like these. We also wouldn't need a bunch
| of superficial nonsense most developers believe they
| cannot live without. Most companies drastically over
| spend on finding and retaining developers that aren't
| qualified to be there in the first place when really in
| most cases it's just about trying to put text on a
| screen. These companies would save so much money finding
| people off the street, evaluating them against minimally
| required intelligence and just training them to read and
| write code in house.
| lelanthran wrote:
| > Uugggghhh... "maintainable way" is again super
| subjective.
|
| It's not "super subjective" when something super niche
| like Haskell[1] is chosen.
|
| There are pragmatic reasons to choose a tech stack, the
| biggest of which is "can we find people to maintain it?".
| If you cannot, then it's unmaintainable.
|
| [1] That's the example that was chosen upthread.
| whateveracct wrote:
| You know there are entire companies using Haskell in
| production successfully and have been for years, right?
| oblio wrote:
| The number of companies using boring old Java, C#, C++
| dwarfs your number by several orders of magnitude.
| intelVISA wrote:
| The "genius" who transforms complex systems into Eldritch
| horrors and the "swore an oath to never reinvent the wheel"
| glue engineer are equally as damaging imo.
| pl90087 wrote:
| And the problem our industry has is that these concepts are
| not well-defined. You can easily have engineer A strongly
| claim that the code that was put in front of them from
| engineer B is terribly designed and will be unmaintainable
| and then they write an alternative proposal that they love,
| and then the next guy C comes with the exact criticism of the
| alternative, and the twist is that C is actually B, the guy
| who wrote the originally criticized code. You can watch this
| kind of stuff first hand here in HN discussions. It's so sad,
| it's actually pretty comical again if you are not vested in
| it.
| highwaylights wrote:
| The solution is D, which means we come up with a
| methodology that solves problems A-C and then mandate that
| everyone sticks to it.
|
| And now we have problems A through E.
| letitbeirie wrote:
| Oblig: https://xkcd.com/927/
| haweemwho wrote:
| [flagged]
| z3t4 wrote:
| The solution is that the one who write the
| software/architecture is also the one maintaining it. When
| it comes to writing easy to maintain code, that can only be
| learned by maintaining code for a long time. If that dude
| leaves the team and you have no one that can edit it, just
| rewrite the code from scratch! So you basically want to
| follow the Unix philosophy or micro service architecture.
| This allows you to hire any kind of programmer, you no
| longer need to find someone experienced in programming
| language X, with frameworks Y for platform Z (which is
| impossible), you can hire anyone that is experience enough
| to do the work and let him/her write the software in
| whatever environment he/she pleases.
| aetherson wrote:
| "Rewrite from scratch everything that engineer X touched
| in four years of working here after he leaves" does not
| sound like a feasible approach to development. Also,
| while having good code separation between contractual
| APIs is a good goal and worth pushing towards, the idea
| that nobody would ever have shared ownership of any code
| unit between API contracts is too extreme.
| JohnFen wrote:
| "Rewrite it" is almost always the wrong answer, although
| it can be an overpowering instinct.
|
| Personally, through decades of experience, I've learned
| that when this impulse hits me, I need to consciously
| remind myself of these truths:
|
| 1) The engineer(s) that wrote the offensive code were
| almost certainly not idiots. The code is probably that
| way for a reason, even if that reason isn't obvious to
| me.
|
| 2) If I embark on rewriting it "correctly", the odds are
| very good that I will learn why the code was as it was in
| the first place, and my rewrite will undoubtedly have my
| own style, but will not likely avoid whatever issue it
| was that made me think it should be rewritten.
| meshaneian wrote:
| "The engineer(s) that wrote the offensive code were
| almost certainly not idiots."
|
| Bold statement, but closer to accurate than the first
| impression.
| whstl wrote:
| I've "rewrote" a lot of code in my career. I'm putting
| "rewrote" in quotes, because it was sometimes porting
| from unmaintained programs in obsolete platforms to
| something more modern (sometimes without even being able
| to run them), and other times by doing large-scale
| refactoring that left the codebase almost unrecognizable.
|
| While I agree with #1, that "offensive" code is offensive
| for a reason (no time, no experience, no tooling, no
| hindsight), I don't really agree with point #2. With
| enough hindsight and careful study, it is entirely
| possible to avoid the offensive characteristics while
| doing the same thing.
|
| IMO: bad code is often due to accidental complexity,
| often brought in by the programmers themselves. And very
| rarely due to essential complexity.
| JohnFen wrote:
| Your examples are excellent reasons to do a rewrite.
| Rewriting code is not always the wrong decision. But in
| the main, when it seems that a rewrite is warranted, it's
| a good idea to think long, hard, and objectively about
| why it seems like a good idea.
|
| > With enough hindsight and careful study, it is entirely
| possible to avoid the offensive characteristics while
| doing the same thing.
|
| You're right. I should have been more expansive. The
| rewrite may not reproduce the same issue (although the
| odds are good you'll see what the issue was!), but it
| will have its own issues, and is also likely to
| eventually also become "offensive" code that a future dev
| will have the urge to rewrite.
|
| I use the word "offensive" here in a technical sense, not
| in a judgmental sense. Great code can become offensive
| with time as requirements, environments, and development
| methodologies change.
|
| The main thing is that rewriting code is very expensive
| in both the monetary and risk sense. In the end, it's a
| question of cost/benefit. If the benefit of a rewrite is
| less than the cost, then rewriting is the wrong decision.
|
| > bad code is often due to accidental complexity, often
| brought in by the programmers themselves.
|
| Yes, I agree. And the majority of it turned out bad
| because of maintenance. Too much duct tape and bubble gum
| has accumulated over time.
| convolvatron wrote:
| I find value in rewriting/refactoring it as a learning
| exercise. just take a quick pass. now you are in a really
| good position to talk about what the strengths and
| weaknesses are of the existing version.
| JohnFen wrote:
| Oh, yes, I agree with this. But I count this more as
| "research" than creating production code.
| z3t4 wrote:
| You should not rewrite something that works, only when
| you need to make larger changes, even if the guy who
| wrote the program is still there you might want to
| rewrite from scratch if the requirements change, like you
| now need to handle 100x more traffic and need to have
| something with better performance, or scaled out.
| withinboredom wrote:
| SOLID principles at work. Closed for modification. If
| you're modifying it, you're not doing SOLID programming.
| /s
| sharemywin wrote:
| You both are providing a wonderful example of: "You can
| easily have engineer A strongly claim that the code that
| was put in front of them from engineer B is terribly
| designed and will be unmaintainable and then they write
| an alternative proposal that they love, and then the next
| guy C comes with the exact criticism of the alternative,
| and the twist is that C is actually B, the guy who wrote
| the originally criticized code. "
| Terretta wrote:
| > _You can watch this kind of stuff first hand..._
|
| Something something memory allocating llamas cough.
| wpietri wrote:
| I get what you're saying, but I don't good definitions are
| the problem.
|
| Whether an architecture is objectively excellent doesn't
| really matter. The question is whether the people who are
| going to maintain the thing can work well with it. A tribe
| of OO partisans will produce a very different system than a
| tribe of FP ones. Each could find their own system highly
| maintainable but find the others' incomprehensible enough
| that they'd rather rebuild it than take it over.
|
| What I think really matters is close, respectful
| collaboration among a group of people in a context with
| frequent iteration, so that the team can learn to make good
| choices together. And, over the longer term, enough
| continuity in that team so that new people can absorb
| enough context that the culture is transmitted for as long
| as the code lasts.
| [deleted]
| r00fus wrote:
| So is someone who can grok and refactor an inscrutable
| codebase a +10x engineer (since they fixed a -10x engineer's
| work) or ... something else?
| skrtskrt wrote:
| > an engineer who is not experienced at architecting complex
| systems, goes and architects one when complexity was not
| required in the first place
|
| I have dealt with opposite - a monolith-based company grew to
| a point where more complexity _was_ required, but none of the
| engineers there seemed to have been equipped with an iota of
| distributed systems knowledge.
|
| The "senior" and "staff" engineers obviously built
| _something_ , and everyone was still monkeypatching out all
| the consistency issues 5+ years later, and some of them were
| still around declaring that there are no issues.
| JohnFen wrote:
| > an engineer who writes code that is inscrutable and
| therefore unmaintainable (always by others, often by
| themselves as well).
|
| This is my biggest pet peeve of them all. I tell wet-behind-
| the-ears engineers "always strive to make the life of the
| next person to touch the code easier, even if only because
| the 'next person' will probably be you."
| polalavik wrote:
| I don't know. Tickets can still be busy work depending on when
| you demand them to be done. Sometimes a ticket might best be
| handled at a different stage in the project to give it the time
| and context it deserves. If you are just closing out tickets,
| sometimes out of context and as fast as possible, you are doing
| busy work.
|
| This could just be bad ticket management with where I work. Or
| we use tickets in a less standard way. I'm not sure, I work in
| fpga design so it's not like a user submitted bug, it's a
| request from one of the 1000 review meetings.
| chang1 wrote:
| I've discovered that this can be a deflection tactic for some.
| Usually it happens in a situation where I try my best to
| explain a part of an app or system. The other person is
| overwhelmed or confused but doesn't just say that, and instead
| kicks the can down the road by saying there is a lack of
| documentation to reference or are in need of diagrams. When I
| then take the time to add info to a wiki or spend time
| diagramming concepts with those developers, it seems to not
| help aid understanding at all. Then I realize I just wasted a
| lot of time.
| d23 wrote:
| I'm going to go out on a limb and suggest that the author
| probably thinks a healthy balance exists between zero
| communication and spending 100% of one's time playing JIRA
| games and visibility hacking.
| onos wrote:
| It's a jira version of "talks a lot, has little to say."
| ssgodderidge wrote:
| Agreed. I think the nuance got lost here. "Typical examples"
| is the key phrase here.
|
| Not all presentations are created equal. Text you throw on a
| slide in 10 min to guide a 1 hour conversation, versus trying
| to make everything pixel perfect for 40 hours prepping the
| deck for the public. Ticket management is critical, but do
| you really need to spend 4 hours doing it each day?
| alfalfasprout wrote:
| 1000%. A lot of this stuff seems like busy work to junior
| engineers and bad senior/staff engineers. But this is how you
| spend a few days to save months of wasted effort.
| com wrote:
| I'm a big fan of putting more time and effort into
| communication.
|
| I just think that there's an incredible set of decreasing
| returns after about 30 minutes into building any diagram or
| presentation, for most people and most use cases.
|
| That's why quick whiteboard or lucidchart or Miro sketches are
| so powerful - and are designed to communicate in the moment! -
| and most PowerPoints, swimlane diagrams etc which have tens or
| hundreds of hours of work are like polished turds.
|
| Very few diagrams or presentations show history and almost none
| are ever updated to show the status of things today. Which
| means that they just cause confusion. Generally, someone starts
| again and creates something with new blind spots and which
| takes about as much time again to create, and is out of date
| before others see it.
|
| Drawing and presenting is mostly interesting if the people who
| are present for the drawing or description process can go forth
| and explain, draw or present it in their own words or images,
| and therefore communication has been achieved; this seems to be
| very uncommon in most drawing and presentation-heavy
| environments I've been in though.
| strken wrote:
| I suspect that the presentations and diagrams which need to be
| made, are made. Good communication is important, but the
| artefacts come about from the organic need to communicate an
| idea rather than orders from on high.
|
| Consider "The Bar team wants to know about our new Foo
| architecture" vs "The Bar team needs a 30 minute presentation
| on our new Foo architecture". Does the Bar team actually need a
| presentation, and could it be a live demo? Do they just need
| better documentation? Are they building an integration, and
| would someone from your team working with them for a week
| unblock them in a way a presentation wouldn't? Could this be a
| ten minute call between you and the one engineer who needs a
| hand?
|
| Good and experienced engineers do their best work on open-ended
| tasks. This is as true of communication as it is solo work.
| Artificially dictating the solution without understanding the
| problem limits them.
| robertlagrant wrote:
| > I suspect that the presentations and diagrams which need to
| be made, are made.
|
| I don't think that's true.
|
| E.g. diagrams are made, once, because of an audit, instead of
| made iteratively as the software changes.
|
| Or someone says, "If they want to know, they can just talk to
| me. You know, have a conversation?"
| mgkimsal wrote:
| The whole "yeah, just have a conversation" thing bugs me a
| lot. I like talking, and having conversations. It's rarely
| enough. The information needs to be written down (or
| codified in tests or whatever). Future people won't have
| the luxury of a conversation with whoever originally wrote
| something. Conversations aren't indexable. Conversations
| lose nuance, memories fade or get jumbled. Have your
| conversation, then document/diagram it afterwards.
| gjadi wrote:
| And it's like talking about code and coding. Once you
| start writing you find all^W a lot of
| assumptions/hypotheses you made implicitly or even flaws
| in your reasoning.
|
| Writing is nature's way of letting you know how sloppy
| your thinking is.
| cratermoon wrote:
| Plus, conversations are synchronous. If it's just one
| person explaining to another, it's no so bad. But what if
| that person needs to explain it to five or ten people? Do
| you have multiple 1:1 conversations or try to schedule a
| meeting at a time everyone is available?
| roncesvalles wrote:
| The problem is when engineers make presentations _instead_ of
| writing documentation. The best presentations are when an
| engineer has written a long page of documentation and walks
| through it, interspersed with Alt+Tabs to demos of the
| documented stuff in action.
|
| Too many dysfunctional teams have a culture where engineers
| make a 1 hour presentation at the end of a multi-week
| project, upload the ppt and recording somewhere and call it a
| wrap, without writing a word of searchable and version-
| controlled documentation.
| JohnFen wrote:
| Yes. Presentations are summaries. There needs to be real
| documentation that they're summarizing.
| jupp0r wrote:
| You have never seen JIRA properly configured then.
| mathattack wrote:
| Yes. Disorganization is the largest cause I've seen of
| preventable waste.
| denton-scratch wrote:
| > Common examples include presentations, diagrams, and ticket
| management.
|
| Ticket management is stuff that needs doing, obviously.
|
| Diagrams are illustrations; if something is so complicated it
| can only be understood with a picture, it's too complicated.
| But a quick diagram on a whiteboard (or with a pencil on the
| back of a fag packet) might be helpful.
|
| Presentations (with slide-decks) are for managers[0], not
| engineers. They are a huge drain on time. I got severely dinged
| by my manager for doing a presentation without a slide-deck; I
| hadn't prepared one, because I had real work to do. But I think
| I showed my manager up, because all the other engineers had
| turned up with slide decks.
|
| A crap slide deck is quick to make, and completely useless. A
| really good slide deck can take days to make; it's a specialist
| trade, like making good user documentation. Slides must augment
| the presentation, not distract from it.
|
| [0] I've been forced into formal management once or twice; my
| experience was that at least half of management is bragging to
| other managers about how important your team is, and slide
| decks are great for that.
| danaris wrote:
| > if something is so complicated it can only be understood
| with a picture, it's too complicated
|
| Absolutes like this contribute significantly, depending on
| the perspective they're spoken from, to the anti-
| intellectualism in our society today, or to a culture of
| elitism.
|
| For the first, some things are complex, and that complexity
| is part of the real-life systems and structures they have to
| interface with or represent. Explaining complex things with a
| diagram can be an _extremely_ effective method for making
| what might otherwise require a very high cognitive load much
| easier to process.
|
| And for the second, if someone needs a diagram to understand
| something complex, it's not because they're stupid, and
| insisting that everything worth explaining can--and _must_
| --be explained in text only does them a disservice.
| knsv wrote:
| I find that I write most diagrams for myself as a reader.
| It takes much less time to get an overview some logic I
| have not touched in a while when there is a diagram to
| start with. Once I remember the big picture I dig deeper
| via the code.
| denton-scratch wrote:
| > to the anti-intellectualism in our society today, or to a
| culture of elitism.
|
| It wasn't meant to be an absolute, it is just a rule of
| thumb, and for me. I expressed it that way for rhetorical
| purposes.
|
| I don't think retreating to real language is anti-
| intellectual; but you may be right that it's elitist to
| mistrust stories told in pictures. Anti-intellectuals
| mistrust stories told in words.
| ptx wrote:
| It seems like a good rule of thumb though. Here's a diagram
| of the 11 different tools you need to study to create an
| installer with WiX, which takes literally thousands of
| lines of XML: https://documentation.help/WiX-
| Toolset/tools.html
|
| By contrast, WiX# provides a complete code sample that
| specifies a complete installer in less than 20 lines, with
| no diagram necessary: https://github.com/oleg-
| shilo/wixsharp
| 40yearoldman wrote:
| But at what point does that communication cost more than just
| hiring somebody else who needs less hand holding and less
| "communication" to understand what is going on and figure out
| what to next.
|
| I say this because there always seems to be those who don't
| need this. And it's the ones who need this who never seem to
| produce as much or are able to solve the problems on their own.
|
| So I ask. If you could hire people who need this
| "communication" or hire people who don't need the
| "communication" and they both can get the job done, why would
| you hire those that require time consuming processes.
|
| Good teams don't need Jira, good teams don't need power points,
| good teams don't need all the hand holding. These are tools to
| include those who can't and often bring minimal usefulness to
| the table.
|
| Poor communication is code for "I have no clue what I am doing
| and am going to blame others for why I am not useful, but I
| don't want to admit to others I have no clue what I am doing.".
| Next time you find your self thinking somebody is poorly
| communicating, try this in stead. Say "Hey, I don't know what I
| am doing, I am lost, where can I start? More often than not
| this "poor communicator" is going to be able to direct you to a
| task that will not only make you useful, but also not require
| much more than 5 minutes of exchange and as a result you will
| probably learn something that will make you more useful in the
| long run.
|
| > in my experience it has been the sub-par employees who are
| the ones that don't do this.
|
| To directly call this out, the sub-par are often the ones doing
| all this stuff, because they simply can't do the actual work.
| Sub-par is probably not fair, as a good manager will build a
| team with a few of these folks to tend the toil. So they are
| useful in a way.
|
| Also you all can think back on the time that you hired somebody
| and they knew more than just about everybody about how the
| product works and should work within just a few weeks. This
| person clearly did not need the documentation, they simply read
| the code -- the code is the documentation -- and the quicker
| folks stop thinking like tis anything else other than a big
| manual the faster they will be able to learn new code bases and
| become useful. The constant translation between weird human
| social ideas of what is good communication and a solid
| structured communication such as code its an incredible waste
| of time.
|
| Just remember, your job is to write code to tell a computer
| what to do, and if you can't also read that code to figure out
| what the program should do, you might be computer illiterate
| which makes you less valuable than somebody who can both write
| and read code in the same manner as the systems that will
| consume it.
|
| If you have ever had somebody tell you "it's like you compile
| the code in your head" you will know what I am talking about.
| flumpcakes wrote:
| I think you are confusing communication and competence.
|
| How do you even know _what_ to work on without communication?
| Most real systems are used by real people who aren 't the
| developers themselves. Product owners, business development,
| customer support, and a myriad of other people all usually
| sit outwith the developer teams. Are you talking directly to
| customers for feedback on feature development?
| flippinburgers wrote:
| I think there is a balance but yeah it isn't good if no record
| of "where we are" exists.
| steveBK123 wrote:
| Yes but I think people overestimate how automatable this
| actually is. Where we are context depends on if the audience
| is -
|
| * The next developer to pick up the task where you left off
|
| * Your technical lead asking for update
|
| * Your manager needing an update for his manager
|
| * Product management wanting to know where we are on some
| feature
|
| * End users wanting to know when the bug fix / feature they
| asked for will be in their hands
|
| Everywhere I have worked, we had multiple apps/ticketing
| systems/etc all trying to roll up / slice & dice data to get
| to the above.
|
| In the end it just turns into talking to management pinging
| the next level below them for adhoc status.
|
| Why? Because product is too ignorant to open Jira nor
| maintain status themselves. Because management above the line
| manager level is apparently incapable of opening Jira either,
| let alone 2-3 levels up. Also no one wants to hire real
| project managers anymore to maintain all the different views
| & send the weekly updates they demand to receive.
| dmix wrote:
| Are your tickets even designed/written for consumption by
| product/management?
| steveBK123 wrote:
| Well they were more rigidly formatted for product
| consumption with Acceptance Criteria,
| Milestone->Epic->Story hierarchy creation to roll up to
| larger efforts, tags, Ready For Sprint criteria, standard
| story point sizing,
|
| But very little detail on how one was technically to do
| the task, or time spent discussing technical options &
| tradeoffs.
| steveBK123 wrote:
| And remember, all of the above is a symptom of being in an
| organization where someone more important than you says "I
| don't have time to look at <insert reporting system>, tell
| me what the status of <deliverable> is".
|
| Fixing this from the bottom up is better accomplished via
| updating ones resume & LinkedIn profile.
| ocimbote wrote:
| How to be a 1/10x engineer?
| lispisok wrote:
| _sigh_. The 10x engineer has become tech 's most toxic concepts
| and devs are its victims, yet we keep bringing it up constantly.
| Every time it's brought up it's a new variation that's either bad
| or good but always different than the original proposal of the
| BEST programmers are 10x more productive than the WORST
| developers from a paper in 1968. All that is come of it is devs
| arguing about a hypothetical programmer is and made management
| even more insufferable. The idea is only hurting you, quit
| bringing it up, when it is brought up point out it's a bad
| concept and move on.
| jackblemming wrote:
| The original paper was actually x27 developer or something
| crazy like that. I think Brooks recast it as the x10 developer
| because x27 was too unbelievable.
| 2OEH8eoCRo0 wrote:
| I thought so until I met one. He knew what our team lead wanted
| before he wanted it and would already have it done, along with
| all of his assigned work. He would take initiative and build
| tools that the whole team could use and be more effective with.
| He had a huge impact on me.
| jackblemming wrote:
| That just sounds like a developer who had worked on a similar
| project before, which would obviously look like some kind of
| genius vs those starting from scratch.
| 2OEH8eoCRo0 wrote:
| Negative. He came from working in startups to working in
| defense. The work could not have been any more different.
| He was initially unfamiliar with most of the tools and
| processes that we used.
| varjag wrote:
| Seconded. I was lucky to work with one at my first job, which
| helped to calibrate expectations and set standards for
| myself.
| robocat wrote:
| -10x Engineer: Prevent 1 +10x manager from getting hired.
|
| Encourage doubt and confusion that one person can make a 10x
| difference. Jim Keller is a lizard. Great engineers are a myth.
| Play up to the worst cynical beliefs of management: all
| engineers are just wasteful bums on seats, then prove them
| right.
| justin_oaks wrote:
| To be fair, you're the one bringing up the 10x engineer. The
| article only mentions it for the sake of contrasting it with
| -10x engineers: "+10x engineers may be mythical, but -10x
| engineers exist." And that's all that was said about it.
|
| I agree that arguments for and against are tiring, so let's
| talk about the article instead!
|
| I've definitely seen engineers who have been net negative in
| productivity. They've distracted me from my work, introduced
| bugs that have had severe effects on the production
| environment, and have produced code that had to be thrown away
| and completely rewritten.
|
| Luckily, the items in the article aren't commonly seen all in
| one person, but they are great ways to lose productivity and
| negatively affect others in the company.
| bayesian_horse wrote:
| Normally that role is called a "manager".
| fvdessen wrote:
| Good list but it's It's missing: - "use an new, different and
| exciting technology for each new project, however small"
| bdcravens wrote:
| The self-appointed "10xers" see this as a sign of greatness.
| nailer wrote:
| - Add cool new tech to projects you're working on with ten other
| people. Ensure only one other person knows.
|
| - Name all your variables 'data'.
|
| - Copy and paste everywhere. People will think they've fixed a
| bug, and they have, but you've got seven slightly different
| copies of the function that needed fixing and now there's six
| left.
|
| - Take a project that's using one of those 'prettier' 'black'
| style tools to avoid bike-shedding discussions about linting.
| Change the options because you prefer different ones. Start a
| bike-shedding discussion about linting.
|
| - Use multiple divs for a single circle-shaped avatar.
| surement wrote:
| > Name all your variables 'data'.
|
| Name a class "Entity" and make everything else derive from it.
| Write code that can't be deleted, ever.
| deafpolygon wrote:
| Every micro-managing managers ever.
| zippergz wrote:
| "Change requirements as far into development as possible. To
| avoid blame, obfuscate requirements from the start." -> "Refuse
| to change course even though new information came to light. To
| avoid blame, display extreme confidence in the requirements even
| though there are still unknowns."
| zeteo wrote:
| People can have off days or struggle with certain tasks, but that
| doesn't mean they are intentionally harming the productivity of
| the team. In many cases they just need support, guidance or an
| opportunity to learn. It's highly likely that everyone initially
| joins the company with positive intentions.
|
| However, exposure to cynicism and witch-hunting, such as labeling
| someone a "-10x engineer," can lead some people to become
| disillusioned and potentially adopt harmful behaviors
| intentionally. This can create a vicious cycle indeed.
| martialg wrote:
| 10x engineer is a good meme, but a bad classifier
| cbreynoldson wrote:
| Article's points shouldn't be taken as seriously as the general
| message: be just as aware of the invisible, negative forces that
| hinder employees as you are of the positive forces which stellar
| employees bring. Yin and yang.
|
| Important to note that there are also 10x environments that make
| everyone in them 10x as effective.
| [deleted]
| barrysteve wrote:
| Nice conceptual bulwark against the mythical negative engineer.
| It makes sense to balance out the normal 10x tropes.
| EchoReflection wrote:
| seems like that article is/was kind of a sick joke. i feel like
| reading an article about "how to waste your time/other people's
| time" is...a waste of time.
| mkl95 wrote:
| > Make undebuggable programs. Plaster layers of abstraction over
| everything. Write spaghetti code. Make everything sensitive to
| initial conditions. Avoid pure functions. Use dependencies
| liberally. Say "it works on my machine" whenever possible.
|
| A lot of legacy software is like this. I wonder how many billions
| it costs the economy per year.
| bdcravens wrote:
| The more difficult situation is the legacy software with all of
| those problems that actually makes money.
| perceptronas wrote:
| Its extremely hard to argue for debuggability. I always try to
| prioritize how easy is it to test the said feature and
| understand it. However, during reviews of other engineers PR, I
| am always met with criticism that there is no need. "Instead of
| localhost, this can be tested on staging" and etc.
| solarkraft wrote:
| Debuggability is a top factor for how long development will
| take. How is it hard to argue for?
| edgyquant wrote:
| >Instead of localhost, this can be tested on stagin
|
| No, it must pass a preview before being merged into staging
| medo-bear wrote:
| if 10x engineer writes in lisp, then that must mean that -10x
| engineer writes in forth
| sebringj wrote:
| I might be skipping the competence part but personally my
| performance has been directly correlated to how much I care about
| my team/org. My attention is focused and goal oriented in a
| proactive way when I do care but passive and reactive when I just
| want a paycheck. I don't have good advice to spot how people care
| so its not super helpful but people that don't attempt to help in
| hairy situations or seem withdrawn from conversations are
| probably not on the good end of things.
| rpastuszak wrote:
| Normalize and support deviance: https://danluu.com/wat/
| hermannj314 wrote:
| I got burned out and lost a few years of my life due to a job
| like this.
|
| We had two things:
|
| a. Poor systems and poor communication permeated the IT
| department
|
| b. IT was viewed as a cost center so no amount of heroic
| intervention was ever rewarded proportionately to business
| impact. It was Sisyphean.
|
| If you are in a situation like this, please run away. You can't
| win - either the free market will destroy your employer, or your
| employer will destroy you.
| baal80spam wrote:
| > IT was viewed as a cost center
|
| Serious question: isn't it always?
| NortySpock wrote:
| Not if the people who develop valuable new product features
| are embedded directly in your IT department.
|
| Basically, if IT + Product Development are in the same
| financial "bucket", IT can be viewed as directly supporting
| product development.
| lifeisstillgood wrote:
| >>> inconspicuously waste others' time, write lengthy
| messages/documents and share as widely as possible. Welcome all
| opinions and aim for engagement.
|
| Mostly spot on but I am not sure of this one - well written notes
| / emails about technical issues and some of the trade offs or
| desired outcomes are really useful - they actually help "align"
| people. Think more "Linus rant" than "CEO powerpoint" but the
| idea is there
| Jolter wrote:
| Sharing those too widely is hugely counterproductive though. It
| will engage people who have no business with it. It's what
| Yammer does to an organization -- introduces all the
| disadvantages of Twitter with few of the benefits.
| quietthrow wrote:
| Does it bother anybody that he is promoting his own article by
| posting it? I have seen this and many other comments by this user
| as what seems like a funnel to book time with him and eventually
| be a paying customer. I am not sure how I feel about this.
| dgs_sgd wrote:
| I think it's fine as long as the content is suitable for
| hackernews
| surprisetalk wrote:
| I've been writing/posting a lot lately because I got laid off
| recently :)
|
| Honestly, I've just been yearning to meet new people who love
| making things.
|
| It's super fun chatting with strangers on the phone!
|
| EDIT:
|
| Actually, if y'all have extra money lying around, consider
| donating to my AIDS/Lifecycle campaign :)
|
| Improve living conditions for people with HIV/AIDS
|
| [1] https://giving.aidslifecycle.org/participant/taylor
| davedx wrote:
| > Trap 10 engineers in a futile skunkworks project.
|
| LOL, I thought I was cynical
| d--b wrote:
| A lot of toxic negativity in that post.
|
| Sure bad engineers exist, but you know what is even worse than
| the -10x engineer: the contagious jerk.
|
| https://www.inc.com/jessica-stillman/studies-being-a-jerk-is...
|
| Yep being an asshole spreads like a disease within organizations.
| Avoid these guys like the plague.
| d23 wrote:
| Why do you believe the traits and behaviors outlined in the
| article are mutually exclusive with being a jerk? In my
| experience, most of the toxic people I've worked with were
| toxic because they exhibited a number of these traits and were
| thus ineffective and using toxicity to compensate.
| coldtea wrote:
| > _A lot of toxic negativity in that post._
|
| Yeah, or as it's scientifically called: "realism"
| brodouevencode wrote:
| I get the sense that this is an investor/bankroller that
| fancies themselves as an engineer, or a manager that has done a
| terrible job of hiring so far.
| ilyt wrote:
| It's not 0/1 problem. Obviously being asshole for no reason is
| bad.
|
| But bending over backwards for bad solutions just coz you
| "don't want to rock the boat" or "don't want to argue" leads to
| mediocre product driven by whoever happens to be least polite
| in the team. Tiny bit off stubborness and assholery on stuff
| you know is right (as in when nobody can provide actual
| sensible arguments for other way) can be very helpful.
|
| Also I did worked with "toxic but brilliant" ones and honestly
| I vastly prefer it over nice useless people. Toxicity can be
| managed, uselessness can not.
| peoplefromibiza wrote:
| the "contagious jerk" is simply the result of a bad environment
|
| the first one to denounce it encourages other colleagues to
| speak up, like it happened with the metoo movement.
|
| http://www.quickmeme.com/img/13/13d4f6f146baa91dbc0946651ca0...
| surprisetalk wrote:
| Author here.
|
| I don't want to empower jerks.
|
| Anything particular I should change? Or is the structure of the
| essay too cynical overall?
| robertlagrant wrote:
| Huh, that's cool. I would say:
|
| - if you can't define "jerk" well, you're playing into office
| politics. Who decides who the jerk is?
|
| - there's a typo: "A blog post by the studies authors" should
| be "A blog post by the study's authors"
|
| - the "studies" linked to seem fairly dubious. Most people
| who are rude are not so because their boss is. Only 25% said
| they were. Also, it's qualitative survey data, which it's
| rarely a good idea to draw anything but first order
| conclusions from (e.g. yes Donald Trump won the 2016
| election, so we can conclude that he got the most votes, but
| we can't infer from that that voters like candidates with
| orange skin). And as self-reported data, it's hard to base
| much on it at all.
|
| - the implication is that removing all this would be the best
| thing, and that's probably true: having some wonderfully
| polite geniuses is no doubt the best option. However that
| doesn't mean we should necessarily prioritise politeness over
| raw ability, as at least for some tasks, a solitary person
| who's very smart can do things that even teams of others can
| do.
| s-j wrote:
| The article is good at making a point of what is bad and for
| the fun of it. However, it is not successful at
| compassionately explaining what one should strive to instead
| as there is no simple negation of the points being made.
| jerf wrote:
| It is not the responsibility of a person pointing out
| problems to also solve them.
|
| Granted, pointing out problems is generally much easier
| than solving them, and correspondingly less valuable. As I
| like to say, stand up, spin around, and point at something
| randomly. You're pointing at a problem of some sort.
|
| But that still does not incur a responsibility to someone
| pointing out a problem to also solve it. It's a popular
| idea for some reason but not one that can stand up to
| scrutiny of any kind.
| camjohnson26 wrote:
| No but it is their job to understand it, otherwise you're
| not contributing anything valuable, you're stirring up
| drama. If I point to a light switch and call out it's a
| problem that does you no good unless I tell you why, and
| why it's like that in the first place.
|
| The problem with the article is even though it's right it
| makes no attempt to explain why, and blames bad people
| for the problems instead of understanding why they might
| be acting like they are.
| jerf wrote:
| "No but it is their job to understand it,"
|
| No, it isn't their job to understand the problem before
| pointing it out either. That also does not stand up to
| scrutiny in the slightest.
|
| If I call my township to report a big pothole, I am not
| required to submit an explanation of how the pothole came
| to be. This is a ludicrous standard only deployed when
| situationally convenient for someone, not an actual
| principle.
|
| Again, the _value_ of a problem report without an
| understanding may be less than one that has it, but there
| is no obligation to have an understanding or present one
| in order to talk about a problem at all.
| watwut wrote:
| >No but it is their job to understand it, otherwise
| you're not contributing anything valuable, you're
| stirring up drama
|
| Frankly, this sounds exactly like toxic management where
| people are not allowed to raise issues which then blames
| everybody but themselves for consequential infectivity.
|
| > If I point to a light switch and call out it's a
| problem that does you no good unless I tell you why, and
| why it's like that in the first place.
|
| I I point to a light switch and say that it does not
| work, I do not need to be able to fix it by myself. For
| that matter, it is good example, because we are not even
| allowed to fix electric devices by ourself (workplace
| safety).
| camjohnson26 wrote:
| Taking the bare minimum of time to understand a problem
| before complaining about it isn't toxic, it's human
| decency that respects other people's time. If I called
| out every problem with all the code I work with no one
| would ever get anything done, because everything is
| tradeoffs.
|
| I don't think you're saying that you couldn't explain why
| the light not working is a problem. No one said you have
| to know how to fix it.
| watwut wrote:
| Except that, demanding that people have solution, which
| is what parent did and "taking the bare minimum of time
| to understand a problem" are two massively different
| standards. The original article definitely clears the
| "taking bare minimum time to understand a problem"
| standard. Neither parent nor you are content.
|
| > If I called out every problem with all the code I work
| with no one would ever get anything done, because
| everything is tradeoffs.
|
| Obvious difference is that article did not complained
| about trivial issues. It complained about very real
| issues that waste massive amount of time.
|
| > I don't think you're saying that you couldn't explain
| why the light not working is a problem.
|
| Adding "I do not see without light" is completely
| unnecessary when complaining about broken switch. There
| is zero need for it. Similarly, it is no mystery why
| issues in article are problems.
|
| If you are unclear about why any of listed issues is a
| problem or disagree, you could have made that claim. But,
| neither parent nor you claimed not understanding that.
| All you want is to prevent people from talking about
| these issues.
| camjohnson26 wrote:
| I never said the article should have solutions, or that
| the issues in the article are not problems, or that they
| shouldn't be talked about. If you want to assign a point
| of view to me that I don't believe then this is a
| pointless discussion.
| censor_me wrote:
| [dead]
| nyob wrote:
| I think it's great and on point. No need to change anything.
| __MatrixMan__ wrote:
| I don't think it's too cynical overall.
|
| I can't recall the quote verbatim, but somewhere in "The
| Glass Bead Game" a great teacher says that it's difficult to
| work with intelligence--you have to be lucky to identify it
| and then the best you can do is get out of its way.
| Stupidity, on the other hand is easy to identify and easy to
| correct on a case-by-case basis.
|
| There's value in inverting a problem like you've done in the
| article. It might not be symmetrical. Things that might not
| have been obvious in the original become obvious in the
| inversion.
| luxuryballs wrote:
| don't let the -10Xers get you down it's a delightfully funny
| and insightful piece
| d--b wrote:
| It's brutal.
|
| You want to sound like an Office Space character. But in
| Office Space, there is no mission, there is no good
| engineering to do. So all the douche-y people who get in the
| way of work are more pityful than enemies.
|
| But here, you believe in good engineering yourself, and the
| -10x engineer you encounter get under your skin. So you're
| venting online about why you hate their guts (in a funny way,
| for sure, but still the aggressivity transpires)
|
| It's understandable. I met many bad engineers. They're a
| nightmare to work with. And yes, many will have a net
| negative impact on overall productivity. Still, coining the
| term -10x engineer and making an aggressive piece about all
| the ways they can screw your work life is not exactly
| healthy.
|
| Yes, I think your post is going to be empowering jerks. What
| did you think? That this was just a "funny, haha" post? There
| are many people who are angered by bad engineers in their
| daily lives. This is just adding fuel to their anger. This is
| the Jerk effect taking place. This article reads like a jerk
| venting, and that language will spread to frustrated people.
| You can already see it in the comments here.
| d23 wrote:
| There's a lot of projection going on here, as far as I can
| tell. The author is about as neutral as possible in
| describing these traits / behaviors. None of these traits
| are mutually exclusive with being a jerk, and in my
| experience, more often than not the people that exhibit
| these traits tend to also be jerks to compensate for their
| inability to get high quality work done!
| d--b wrote:
| If you can't see the negative bias in calling anyone a
| "-10x engineer", I just can't discuss the matter with
| you...
| d23 wrote:
| If it were directed at a particular person, sure.
| Otherwise, the author is describing negative _traits and
| behaviors_. Have you ever taken any management training?
| This is the quintessential way of discussing these sorts
| of things neutrally. Yes, you 'd never want to call an
| individual a -10x engineer, but this is a random article
| on the internet. It's okay to be a bit headline-
| attention-grabby and stylistic so the article isn't dry
| and corporate.
| d--b wrote:
| You know what. I do agree with most points in the
| article. And I do find them funny.
|
| Yet, I also met an awful lot of terrific engineers who
| were brutally aggressive towards anything they felt was
| stupid. And in my opinion, those people cause at least
| just as many problems as people who perform really
| poorly.
|
| I think the tone of the article (cynical, exagerating bad
| traits, etc.) promotes that kind of toxic culture, while
| not bringing much to the table in terms of fighting
| mediocrity. That is all.
| d23 wrote:
| Fair enough, thanks for clarifying. I haven't run into
| too many of those people (brutally aggressive _and_
| terrific engineers). The toxic people I 've run into
| spent all their time trying to look smart to cover their
| incompetence.
| Nuzzerino wrote:
| No changes needed, it grabbed my attention and stood out. You
| clearly know what you are talking about.
|
| But assuming your goal is to make a positive impact in the
| industry, managers need to be able to read this and get
| actionable takeaways.
|
| You've got my attention as an engineer, but a follow up post
| for each of these examples would be the place to close the
| deal. They of course would have to be written with a
| different (and dare I say more constructive) slant. It needs
| to be something someone can take to a manager and get a
| chance of some good conversations. It can still be
| persuasive, but in order to be actionable I would expect
| specific examples, clear definitions of the issue, and
| recommendations that tend to be familiar or standard.
|
| I would do plenty of research too. Because for one thing you
| need to ensure you are giving correct advice. But it will
| provide a massive boost to your credibility to include that
| research in the posts. It will also save your reader the
| trouble of doing independent research (which they likely
| would not have done in the first place but still require it
| for actionable change, or the idea gets shelved). -10x
| engineers can leave managers no time to do that kind of
| diligence, but the managers still know better than to blindly
| trust what someone says on the Internet. Back up your
| arguments with evidence where possible.
|
| I know it's a tall order but if you have the time to put that
| much quality into a series from this, it could be great. I
| only say this because from what I can see, you do know what
| you are talking about, and clearly have passion about this.
|
| I look forward to reading anything you do come up with,
| whatever the approach :)
| itronitron wrote:
| You could have really shortened your list by just starting
| off with 'Use JIRA'
|
| Also, the thing about wasting 10 weeks of wages on cloud
| computing was confusing because it mentioned buying exotic
| hardware and in my experience the options via cloud computing
| are never exotic, and never have a decent amount of RAM.
| efitz wrote:
| Software needs to be used by users. It's unlikely your
| developers are so innately talented that everything a user
| wants to do is obvious and intuitive. So docs, etc matter.
|
| Other teams like marketing need to make schedules because
| they spend huge amounts of money doing things to make your
| product successful, that have nothing to do with code. For
| example, launch events, advertising, conferences, executive
| briefings for key customers, etc. Planning, dates, progress
| reports, etc are all needed because unless you are a lone
| open source developer, you have to work with others.
|
| Users will use your software in unexpected ways. Hackers will
| try to break it. And users will expect it to work flawlessly
| when they need to use it to generate their report for their
| VP meeting in 5 minutes. Testing is critical to ensuring that
| your software doesn't suck for your users and make them hate
| you.
|
| The business you work for probably doesn't exist with the
| mission to leave you alone and let you code. They want to
| solve a customer problem by creating, marketing, selling
| and/or supporting a software product. Your management wants
| to know that all the money they are spending on your salaries
| is getting them a positive ROI. Letting them know what you're
| doing and providing them with content about capabilities and
| features that can be used in marketing, makes them want to
| keep paying you. Missing deadlines, failing to deliver non-
| code deliverables, failing to provide status, and being jerks
| in general make management want to cut your project (and
| maybe your job) and do something else with cooperative
| people.
|
| Yes, there are pathological extremes to all of these things
| and to the points you raised in your post, but I see too many
| developers who think that developing software is just about
| coding and that everything else is extraneous. In reality,
| the vast majority of your time is probably best spent NOT
| coding.
|
| [ed] spelling, paragraph break
| photochemsyn wrote:
| > "They want to solve a customer problem by creating,
| marketing, selling and/or supporting a software product.
| Your management wants to know that all the money they are
| spending on your salaries is getting them a positive ROI."
|
| This is all true for the somewhat narrow field of
| commercial software development for the consumer end-user
| where profit margins determine success or failure in terms
| of paying off the capital investors, but many organized
| engineering efforts have other goals, e.g. replacing some
| organization's decrepit internal data storage, archiving
| and retrieval system where robustness matters more than
| anything else, or designing a research program aimed at
| solving a complex technological problem, writing software
| that controls an electrical grid, and so on. Applying the
| maximize-short-term-profit mentality to such problems
| generally doesn't end well.
| secfirstmd wrote:
| Well said. I work on engineering stuff but I spend a huge
| amount of time encouraging people to understand the other
| parts of the business and their needs.
| goodpoint wrote:
| I'm surprised you don't stress more on the habit of always
| picking the popular google-scale tools even for in smaller
| companies. Or the language or framework of the month lol.
| CropCircleSys wrote:
| No. I enjoyed the article and your sense of humor. Kudos
| Clubber wrote:
| I've been writing software for 20+ years. I think that
| article is pretty funny and on the nose. I'm currently in the
| midst of fixing an issue we just discovered added by a -1x
| engineer _17 months ago_. He 's the gift that keeps on
| giving.
|
| If you're offended, this article is probably for you.
| d23 wrote:
| It's fine. It's clear the purpose is to list a bunch of
| traits and observations you've made over the years. It's
| concise. Trying to fluff it up would only make it less
| readable.
| justin_oaks wrote:
| The only thing you should change is your expectations.
|
| No matter what is written, someone will find something wrong
| with it. Expect those people to show up and sometimes be very
| loud.
|
| I appreciate your efforts to receive feedback. In this case,
| you'll find the majority of people aren't complaining, just a
| few are. So be happy that you wrote something that so many
| engage with!
|
| The only thing worse than writing something that people are
| critical of is writing something that's completely ignored.
| EGreg wrote:
| Nothing. Your essay exists solely to be criticized, and
| honestly you're on a bad / useless path and should get out
| now and completely rethink your life.
|
| We are HN. We are legion. Expect us.
|
| When I got on the site, btw, I immediately saw your choice of
| font and I didn't actually read your essay.
|
| PS: This is satire
| (https://en.wikipedia.org/wiki/Poe%27s_law)
| rvba wrote:
| Let me guess, everyone who criticizes you is a jerk?
| CM30 wrote:
| What's more, the contagiousness aspect isn't the only issue
| here. Jerks tend to cause problems for organisations for other
| reasons too. Such as:
|
| 1. They scare away a lot of competent workers, since many smart
| and talented employees won't want to be stuck working alongside
| an asshole, regardless of how 'talented' they might be. And
| given that the best employees tend to have a plethora of
| options for where to work, and well... you can guess how that
| affects the talent remaining.
|
| 2. They discourage newer and less experienced employees from
| learning/improving, and instead encourage them to leave. But
| folks who aren't necessarily the most talented developers now
| can very much turn into such with the right environment and
| incentives, which these types of people don't provide.
|
| There really aren't any benefits to keeping around jerks, and a
| whole lot more downsides than people think.
| tasubotadas wrote:
| Did you find yourself on that list? Because besides this
| explanation, there is 0 toxicity.
| [deleted]
| technofiend wrote:
| I worked with one person who weaponized pedantry. He thought he
| was educating everyone by being a complete stickler for his
| specialized vocabulary and would never just answer a bloody
| question, wasting everyone's time. He thought he was Socrates
| but he was the hemlock. Similar to a good project manager he
| was like a chain-saw: very effective, but you always want the
| tool pointed away from you. It also meant you really thought
| about whether you could get what you needed done with any other
| tool rather than pull out the chainsaw. Ultimately this kind of
| behavior is a productivity sink; forcing everyone into your
| rules because it'll be so much better when everyone just
| complies with how you need the world to be means getting worked
| around and giving the pedant's work to someone more pleasant to
| work with.
|
| Please note: I'm not dinging people who sincerely need
| structure to help them function. This was a conscious choice
| just to be a jerk because in that person's opinion everything
| would be great as soon as we all thought exactly like he did.
| SilverBirch wrote:
| I find it's context dependent. Sometimes everyone is working
| hard and doing their best and someone's being a toxic jerk.
| Sometimes things are going badly wrong and you _need_ someone
| to actually stand up and say "Hey, how come these requirements
| keep changing we've wasted months doing something that was
| totally useless" or "Hey, how come our AWS bill is $100,000,
| and hang on a second, why isn't anyone monitoring our AWS
| bill?" or "Hey, the core premise of this project turns out not
| to be true, maybe we should really re-evalaute rather than
| ploughing on".
|
| Sometimes requirements are unclear and you just have to learn
| as you go. Sometimes the AWS bill is the last of your porblems.
| Sometimes you find out something you had assumed at the outset
| is wrong, but you still believe in the project. It's context
| dependent.
|
| Also, it's often more difficult to be the person asking the
| hard questions than the person who just goes along with things.
| time0ut wrote:
| I read the post, saw this comment, then re-read it again. I did
| not get the impression that author was trying to be negative. I
| think they were just trying to write in an "edgy" style. I've
| seen most of the things on the list happen (at least to a
| degree).
|
| On the topic of contagious jerks, my experience has been that
| these people often suck at engineering.
|
| For example, a few years ago, one of the product managers was
| super excited to recruit an engineer they had worked with
| before. The engineer was talked up. A real genius. Someone who
| would come in and do things right. He would lead a new sibling
| team working on a new product. I was excited. We could use the
| help as we were going through hyper-growth.
|
| The engineer seemed smart, but had a very sarcastic and
| negative attitude. The existing architecture was garbage.
| Everyone's code was terrible. Even the choice of language was
| wrong. While he was respectful towards me and the work I had
| done, I saw him put down most of the people around him. I kept
| my distance and let him do his thing. It wasn't my place in the
| organization to interfere anyway.
|
| The end result was he drove half his team to quit, delivered an
| absolute disaster of a system, and then left.
|
| I've seen versions of this play out a few times. My experience
| has been that the smartest people are often the nicest because
| they are smart enough to recognize the value in lifting
| everyone. I know its not always the case and I have worked with
| difficult people who genuinely were incredible engineers as
| well, but they tend not to actively put everyone around them
| down.
| naillo wrote:
| Step 11: Call out any attempt to make engineering more
| productive as toxic negativity.
| ilyt wrote:
| Step 12: have a meeting about it
|
| Step 13: have a blogpost about how inclusive and equitable
| your company is.
| vxNsr wrote:
| Step 14: Hire an entire team who's only job is increase
| office drama and reduce colleagues trust
| ilyt wrote:
| Step 15: Make absolutely sure your team and any
| prospective hire knows you will hire to fill quota vs get
| them the most competent co-workers, ensuring mediocrity.
| psychoslave wrote:
| Step 16 skip step 16.
|
| step 17 Recognize that questioning the status quo is a
| critical part of progress and growth, and that "toxic
| negativity" is often a label applied to dissenting voices
| to silence them.
|
| step 18 Acknowledge that engineering, like any other
| field, can benefit from improvements in productivity and
| efficiency.
|
| step 19 However, also acknowledge that a singular focus
| on productivity can lead to shortcuts, neglect of
| quality, and burnout among engineers.
|
| step 20 Question any proposal that seeks to boost
| productivity without considering its potential drawbacks
| or unintended consequences.
|
| step 21 Encourage open and honest discussions about the
| tradeoffs involved in increasing productivity, and
| welcome feedback and criticism.
|
| step 22 Remember that criticism is not the same as
| negativity, and that constructive criticism can help
| identify problems and find solutions.
|
| step 23 Avoid dismissing criticism as "toxic negativity"
| or labeling critics as "problematic" without engaging
| with their ideas.
|
| step 24 Recognize that diverse perspectives and voices
| are essential to a healthy engineering culture, and that
| dissenting opinions can lead to innovation and progress.
|
| step 25 Cultivate a culture of respect and openness,
| where all voices are heard and valued, and where
| criticism is welcomed as an opportunity to improve.
|
| step 26 Challenge assumptions about what constitutes
| "productivity" and explore alternative approaches that
| prioritize quality, sustainability, and employee well-
| being.
|
| step 27 Remember that engineering is a human endeavor,
| and that the well-being of engineers and the communities
| they serve should be a top priority.
|
| step 28 Take a shortcut and jump directly to step 42 for
| your surprise.
|
| step 29 Recognize that productivity gains should not come
| at the expense of ethical considerations or compromises
| in safety standards.
|
| step 30 Encourage ongoing learning and professional
| development among engineers, so that they can remain up-
| to-date with the latest technologies and practices.
|
| step 31 Ensure that engineers have access to the
| resources and tools they need to be productive, without
| sacrificing their mental or physical health.
|
| step 32 Celebrate successes and learn from failures,
| without casting blame or assigning fault.
|
| step 33 Remember that productivity is just one aspect of
| a successful engineering organization, and that teamwork,
| collaboration, and communication are equally important.
|
| step 34 Foster a culture of trust, where engineers feel
| empowered to speak up and share their concerns without
| fear of retribution.
|
| step 35 Recognize that engineering productivity can be
| influenced by external factors, such as economic
| conditions or resource constraints, and that some
| challenges may be beyond an individual's control.
|
| step 36 Encourage interdisciplinary collaboration and
| cross-functional teams, to break down silos and encourage
| a diversity of ideas and approaches.
|
| step 37 Always be open to feedback and criticism, and
| recognize that even the most successful organizations can
| benefit from continuous improvement.
|
| step 38 Emphasize the importance of work-life balance,
| and support policies that allow engineers to take breaks,
| recharge, and avoid burnout.
|
| step 39 Encourage knowledge sharing and collaboration
| across teams and departments, to foster a culture of
| continuous learning and improvement.
|
| step 40 Seek to understand the root causes of any
| resistance to productivity improvement, and engage in
| constructive dialogue to address those concerns.
|
| step 41 Consider the long-term consequences of any
| productivity-enhancing measures, and make decisions that
| promote sustainable growth and development.
|
| step 42 Realize that in this message only steps 16, 28
| and this one where not generated by ChatGPT.
| justin_oaks wrote:
| Ah, step 42. Well done.
|
| I was wondering why all these steps were generally GOOD
| things to do instead of the BAD things that all the
| previous steps were (1-15). And I was wondering why they
| all sounded the same.
| marcosdumay wrote:
| They sound exactly like the stuff the people from step 14
| write, while doing the exact opposite.
| IshKebab wrote:
| He isn't saying that. Maybe you've never had the misfortune
| of working with someone who is just _always negative_ but it
| is really draining. Those people aren 't trying to make
| engineering more productive, because that would involve being
| positive and looking for solutions instead of just constantly
| complaining which is what they actually do.
|
| Fortunately they're relatively rare in my experience. I've
| only worked with one or two.
| pydry wrote:
| This.
|
| I've seen the behavior OP calls out more commonly
| _associated_ with toxic behavior than the reverse.
|
| The suspect the people who manufacture make work for others
| to justify their existence are often aware of their
| redundancy on a deep level. That frequently manifests in the
| form of toxicity when their make work is challenged. You're
| challenging their meal ticket and house-of-cards identity all
| at once.
| BoneZone wrote:
| I disagree.
|
| For me this outlines the caveats and pitfalls of software
| development and management.
|
| There is real truth to some of the authors points showing real
| paths that emerge naturally.
|
| If you're going to gaslight him by inferring anyone who is
| critical is an asshole, maybe you should ask yourself why
| you're taking the article so personally...
| lifeisstillgood wrote:
| Well put.
| burnished wrote:
| Gaslighting is a pretty serious accusation, its weird to see
| you use it so casually.
| nonethewiser wrote:
| Very overused in online discussion. It requires intent
| which there is virtually never evidence of. Without that it
| might as well just be a difference in opinion. Its
| prevalence speaks to how intolerant people have become.
| d--b wrote:
| Am I saying that anyone who is critical is an asshole? Where?
| Seriously?
|
| I find that the article hides a deep aggressivity towards
| overall mediocrity behind a thin veil of office-space-like
| humour. And I think that aggressivity is contagious and so
| not a good thing to spread.
| throwawayforall wrote:
| [dead]
| ouid wrote:
| You're going to have to be more specific at this point.
| mmcnl wrote:
| I agree. Be professional. Assume good intent and keep your
| opinions for yourself when nobody is asking for it.
| DangitBobby wrote:
| You didn't say it outright, but it was exactly what I
| inferred from your comment as well. You said "toxic
| negativity" which comes across as a moral judgement, and
| anything that follows comes across as the result of that
| judgement.
| d--b wrote:
| It was a judgement. I do think the author is being a jerk
| here. But people can be critical without sounding like
| jerks.
| psychoslave wrote:
| Maybe avoiding to use pejorative wording would make a
| more convincing argument to promote a view still
| accepting meaningful advises through criticism, while
| judging unethical any form of essentialism view which
| reduces some people to despicable traits, rather than
| presenting a situation where some people are entangled in
| abject behaviors.
| [deleted]
| DangitBobby wrote:
| I don't think it's reqlly fair to read a person's
| frustration piece and assert they probably have a
| character flaw. I don't even see your issue with the
| article, really. I don't think it's targeting anyone
| specifically and it seems to be about doing things in
| excess. Maybe just the idea of people who are
| consistently negative contributors rubs you the wrong
| way.
| camjohnson26 wrote:
| I agree with most of the author's points, but the post is
| overly negative in my opinion. It's blaming other people for
| the problems instead of digging into why these problems come
| up in the first place. Why do managers waste time with
| busywork? They need insight into the process. If you look to
| criticize without understanding you'll always find plenty of
| material to blog about, but you'll just create new problems
| and never fix anything.
|
| The author probably thinks these issues are caused by bad
| people instead of bad processes, which is why he doesn't
| suggest realistic fixes.
| surprisetalk wrote:
| _> The author probably thinks these issues are caused by
| bad people instead of bad processes_
|
| Author here.
|
| This is an _excellent_ way to phrase a subtle point that I
| couldn 't figure out how to fit in the piece.
|
| I think that -10x engineering is not someone you are, but
| something you do. And even more commonly, it's something
| that _organizations_ do for periods of time.
| RheingoldRiver wrote:
| I think this is something that would've been great to
| include as an intro, and would've completely removed the
| negative atmosphere that some people (including myself)
| got from the article.
| 6510 wrote:
| how to become..
| Jolter wrote:
| The title makes a lot of sense because of the meme "10x
| engineer". That is also wrong - being 10x more productive
| is also something you do, not something you are -- but I
| see the point in following that template.
| m3kw9 wrote:
| That's not what he said about anyone critical is an ass, he's
| say rather than -10x, worse for a company are assholes and
| they do exist
| postalrat wrote:
| I can deal with assholes who get stuff done. Developers who
| are consistently making negative progress are harder to
| deal with.
|
| -10x developers can get the just by promising things people
| depend on but never deliver.
| m3kw9 wrote:
| Usually is easier to deal with -10x devs than assholes
| because they are likely devious is not easy to handle. A
| crapy dev can be dealt with when you present their git
| commit to the manager/lead
| infamouscow wrote:
| Stupidity is a moral failure. Derision of the stupid is morally
| justified: https://www.youtube.com/watch?v=ww47bR86wSc
|
| The study you linked assumes the actors are not stupid.
| goodpoint wrote:
| People here are irked because HN is the home of CV-driven
| development.
|
| EDIT: ...as proven by the rain of downvotes...
| shultays wrote:
| The contagious jerks are often results of working with -10x
| engineers. At some point you become as such, if you don't quit
| the company before that. There are "bad engineers" and then
| there are -10x engineers, it is a real problem if the company
| keeps such engineers
|
| You should try working with -10x engineers and see how your
| feedback is being ignored as tech debts are piling up, products
| are continue to under deliver and missing deadlines.
| Nuzzerino wrote:
| This hits close to home, but unfortunately Occam's Razor will
| get applied.
|
| It's an unfortunate reality that engineers (not their
| managers) are responsible for knowing how to handle
| themselves in the worst of situations so they don't become
| the scapegoat at the cost of their health and security. Trust
| me, I've been through this situation and have been burned out
| by the [apparent] low standards and [apparent] double
| standards.
|
| The prodigal charismatic leader can save the day but become a
| crutch too much relied on. And I get it, with all the shit we
| deal with in life, things ought to work out that way. But
| eventually that leader won't be there for you (or even in the
| picture at all) and you'll be in big trouble, especially if
| you spent many years relying on them for help.
|
| Working remote for a high pressure early stage startup is a
| good recipe for this kind disaster if you aren't great at
| managing stress or conflicts at work.
| CTmystery wrote:
| > To inconspicuously waste others' time, write lengthy
| messages/documents and share as widely as possible.
|
| I transitioned from startups (for 10 years) to a large company
| (for 5 years). Part of that move was adjusting from a culture of
| no lengthy documents to a culture full of lengthy documents, and
| I would never want to go back. Having explicit documentation in
| writing, where folks can debate the merit of ideas is so so much
| better than having it living in a few people's heads, unable to
| be critiqued.
|
| Edit: add a word.
| afterburner wrote:
| I guess you're lucky enough to be in a large company where the
| majority of people actually read and _properly understand_ what
| has been written. I 've had plenty of experience with
| supposedly senior people fundamentally misunderstanding core
| concepts of the technical work.
| saltypepperfox wrote:
| Omg, I knew a PM/Architect combo who fit the bill. Scary how
| quick they came to mind.
| larsrc wrote:
| Missing: Start migrating the code base to new
| technologies/frameworks early, but never finish it.
|
| Though that might actually end up costing more that 400 hours of
| wasted time.
| tetromino_ wrote:
| > To ensure developers are context-switching, recompilation
| should take at least 20 seconds.
|
| I'm now wondering what languages and projects the author has
| worked on if they expect compilation to take less than 20
| seconds. Maybe small-ish golang projects? I don't remember the
| last time I worked on something interesting where recompilation
| was always under a minute...
| truculent wrote:
| Elm has always been very fast in my experience, but I have only
| worked on small-medium sized projects
| wazzaps wrote:
| I worked hard on my previous project to achieve a 5sec build-
| run-test cycle for a medium-sized embedded C project (we don't
| have monster workstations, just some i7-10xxx/16GiB PCs).
|
| Thinking about proper modularization, runtime code (hot-
| re)loading, and eliminating single-point-of-recompilation for
| header files goes a long way.
|
| The gamedev industry figured this out a long time ago, see
| Handmade Hero's Hot reloading[0].
|
| Also, an interactive shell (we use IPython) with all of the
| compiling and debugging utilities you need is easily a 5x
| efficiency boost, e.g. I can run `./devshell.py
| <NAME_OF_TARGET>`, then `run('foo', 'bar')` and the script will
| compile, upload, and re-execute the `foo` and `bar` modules.
| Makes onboarding much easier too.
|
| [0]: https://www.youtube.com/watch?v=Pax5jIz6m_Q
| enlyth wrote:
| Anything written in interpreted languages like
| Javascript/Typescript. UI stuff usually has hot reloading where
| you get "compilation" times measured in milliseconds, and from
| experience restarting even a complex typescript server is a few
| seconds max. This applies to mobile apps as well when using
| React Native.
| belltaco wrote:
| What about Gulp, NPM, Yarn etc. running in the new build of
| UI stuff? Those take up a bunch of time.
| aidos wrote:
| I don't quite get your point. Your parent was pointing out
| that there are interesting projects where the "compile"
| time is milliseconds -- at least for the developer
| perspective. It doesn't really matter that there's a step
| later in the pipeline at takes longer, so long as it's not
| in your way. Also, most of that could be cached away
| anyways.
| Izkata wrote:
| Those are all earlier in the pipeline, required for the
| project to run, and gulp doesn't cache (or, didn't back
| when we used it), which IMO was the main reason webpack
| beat it so quickly.
| narag wrote:
| Delphi used to compile 200k lines in less than ten seconds.
| That was around year 2000, with first generation Pentium. Later
| it slowed down a bit, but not so much.
|
| IIRC, C family compilers suffer from some problem with headers
| that makes compile time much longer than it should.
|
| Edit: oh, and that was rebuilding the whole program from
| scratch, including all libraries. A little change in the
| current file was les than one sec. Native code, in case you're
| wondering.
| fedeb95 wrote:
| the real problem is build time with the windows filesystem (in
| my case). switching to wsl2 you get under 20 sec. pretty
| easily, and most projects > 20 seconds are fixable (that is, if
| someone fixes it). Deploy time, on the other hand...
| flippinburgers wrote:
| What is your measure of interesting? Of "medium" sized? Go
| probably compiles 15K lines/sec.
| hardware2win wrote:
| C# compiler has like tens of milions lines of code and it
| compiles in a minute or two
|
| So you either worked on the biggest codebases in the world
|
| Or youre doing CPP :)
| hibikir wrote:
| A lot can be done, even in languages that compile quite slowly,
| to get good performance in practice. See, for instance, what
| one can do with bazel and build servers. A cold compile is
| still not going to be good, but you'll never do a cold compile,
| and it will be very rare to recompile something that will
| require changing the entire tree.
|
| At an old job, we had files that were slow enough that we'd
| have them in a separate compilation unit (automatic derivation
| of typelcasses with multiple serialization schemes) , so if you
| didn't change them, you'd just be picking up the binary. And if
| you were changing them, you weren't changing anything else, so
| ultimately a very slow compilation step was never a thing.
|
| But yes, it's a matter of investment that few companies are
| willing to make
| didip wrote:
| This whole thing about company/team culture is that it is random.
|
| Even when you are at the best team, culture-wise and
| productivity-wise, accept that this will not last. All it takes
| is for 1 person to arrive/depart to ruin the culture.
|
| Just do your best and bounce when it's time. You cannot move
| Mount Fuji with a teaspoon.
___________________________________________________________________
(page generated 2023-04-04 23:01 UTC)