[HN Gopher] What makes developers productive?
___________________________________________________________________
What makes developers productive?
Author : piinbinary
Score : 133 points
Date : 2023-07-16 13:57 UTC (9 hours ago)
(HTM) web link (jeremymikkola.com)
(TXT) w3m dump (jeremymikkola.com)
| nathell wrote:
| There's one more thing, for me by far the most important: mental
| wellbeing.
|
| In my case, having ADHD and going undiagnosed for decades (I only
| got diagnosed last December) has caused me to blame myself and my
| conscious actions for things directly caused by the
| neurochemistry of my brain. This year may have been my most
| productive ever.
| duxup wrote:
| I just redid a bunch of old code I wrote years ago it was
| pretty hacky and unpleasant.
|
| Why?
|
| I was feeling good about what I was doing and I just kept
| going. I was on a roll.
|
| Many of the changes that were on my list to do that day weren't
| directly related but I was in a good mood. Things are working
| so I did a bunch more.
|
| When you get that good feeling it makes a huge difference in
| the outcome.
|
| If I had felt bad or overwhelmed, I probably wouldn't of been
| nearly as ambitious.
| egesko wrote:
| I went through a similar experience this year. Finally got
| myself checked after I've been called "lazy" for so long, which
| immensely effected my self appointed value. I finally got my
| ADHD meds, and my productivity went through the roof. I tend to
| think what could've happened if I discovered my problem
| earlier, but Im happy that it at least wasn't even later.
| jasfi wrote:
| I agree, and also physical health too. Poor physical health can
| lead to poor mental health.
| [deleted]
| Joel_Mckay wrote:
| One may be surprised to learn the dominant successful trait is
| being incredibly lazy, and finding the simplest minimal-effort
| solution that also requites minimal system-maintenance.
|
| There are some people that are clearly into S&M, that proudly
| bring their kinks into project design.
|
| This is extremely funny, because we all know this is actually
| true =)
| cyb_ wrote:
| Mark Twain is often quoted as saying, "I apologize for such a
| long letter - I didn't have time to write a short one."
|
| In my experience, simple solutions are not the lazy minimal-
| effort ones. It takes a lot of work to distill complex problems
| down into simple solutions.
| kramerger wrote:
| > Knowledge in the developer's head.
|
| > Tooling that reacts quickly.
|
| > Helpful infrastructure
|
| Android developers would find this list depressing: huge SDK that
| never stabilises, Android Studio is the new Crysys, Gradle (and
| its scala dsl) is just confusing.
| agumonkey wrote:
| Anybody researched CMMI ?
| cyb_ wrote:
| I used to work at a CMMI Level 5 (certified) shop. The process
| was inevitably tailored to the lowest common denominator. It
| was meh.
|
| We used to say that the process will never turn a mediocre
| engineer into a good one but it will absolutely turn a good
| engineer into a mediocre one.
|
| In general, I've observed that a lot of these heavyweight
| processes are used as a substitute for high quality engineering
| leadership. They are not a good substitute.
| agumonkey wrote:
| Thanks a lot, I never had a real experienced based return.
|
| This shifts the problem into defining and growing engineering
| leadership (which was my original quest too)
| 28304283409234 wrote:
| Stop being productive. Just stop. Stop this insane qualification.
| Stop this forever-measure. This race for immer besser, always
| better. It is so saddening.
|
| I came into tech for the joy and the wonder. You don't measure
| joy. You enjoy joy.
| MildRant wrote:
| If you want to be in tech for joy and wonder that's great but
| that's not the same as being in a business. If you want to be
| in business and make money then output matters. It matters less
| to some companies than others but it always matters at the end
| of the day.
| Trasmatta wrote:
| Or just maybe there's a way for us to prioritize the human
| aspect of work, such that we can acknowledge how important
| joy and wonder are, while still making money and providing
| value.
|
| Otherwise we're going to just keep burning more and more
| people out. And for what?
| MildRant wrote:
| This isn't an argument against what I'm saying though. You
| cannot be in business expecting it to be 100% joy and
| wonder. You have to be conscious of the "providing value"
| part of your statement. There are companies that have
| excellent work-life balance and provide ample space for
| play. I work for one of them but if the value you provide
| is 0 and you expect a 100% wondrous joyride, you won't be
| there for very long
| Trasmatta wrote:
| > but if the value you provide is 0 and you expect a 100%
| wondrous joyride, you won't be there for very long
|
| I don't see anyone in this thread asking for that
| MildRant wrote:
| The first words in the comment I responded to are "stop
| being productive" but alright.
| lacy_tinpot wrote:
| the eternal dilemma of the min-maxers and the
| roleplayers. the productivity cult are the min-maxers.
| living cannot be min-maxed.
|
| even productivity cannot be min-maxed, save for the short
| term, for the simple reason that we don't know what
| productivity is. technological revolutions are the prime
| example of this, where each turn of each revolution
| shifts the entire idea of what being productive is.
| vinyl7 wrote:
| Infinite growth for the shareholders is the only thing that
| matters these days
| [deleted]
| 28304283409234 wrote:
| Once this site was mainly for Hackers and Painters. Now...
| suits.
| MildRant wrote:
| This site is literally ran by a VC fund. Suits were always
| here.
| 28304283409234 wrote:
| Wasn't talking about ownership, or who runs it. Was
| talking about target audience: founders.
| MildRant wrote:
| Business founders by definition want money. They aren't
| founding businesses so they can generate wonder.
| Clubber wrote:
| Everyone who works wants money.
| prepostertron wrote:
| This site is owned and operated by a startup accelerator.
| It's always been suits.
| 28304283409234 wrote:
| From the faq: "Y Combinator owns and funds HN. The HN
| team is editorially independent. "
| raincole wrote:
| The author of Hackers and Painters is literally a VC
| founder.
|
| And this very site is built by that VC.
| ssrc wrote:
| What I've seen in my career is that when developers were
| motivated by joy and wonder like 2830 said, or by a sense of
| mission, etc. productivity and customer satisfaction was
| high. But when the emphasis turned to productivity (CMMI 5,
| KPIs, OKRs, Big "Agile", punch clock tool in JIRA issues),
| the only thing that went up were numbers in a paper.
|
| It's not that money and output are not important for a
| business, but obsessing with productivity may cause the
| opposite effect.
| Clubber wrote:
| This is exactly right. I hear a lot more people yearning to
| get the fuck out of the industry today than I ever heard in
| the late 1990s.
| dgant wrote:
| I feel much more joy when my builds are fast and my tests don't
| flake. Joy and productivity reinforce one another.
| pxc wrote:
| When I feel joy and wonder at work, I'm incredibly productive
| and I work long hours on top of that. When my senses of
| agency, exploration, and play are undermined, I'm deeply
| demoralized and find it very difficult to focus and can't
| wait to walk away from my computer.
|
| I'm still trying to figure out how to better regulate myself
| away from those extremes (how to put my work down for the
| sake of other aspects of my life when I'm excited on the one
| hand, and how to push through and 'reset' when I am
| frustrated by something outside my control on the other). But
| one of the things I've already learned is that focusing on
| productivity in terms of sheer discipline doesn't really
| work. I get a lot farther working with self-reflection on my
| emotions and carving out space for joy and freedom in the
| formal structure of my work week than with sheer mental
| effort.
| OtherShrezzing wrote:
| The joy and wonder you feel in tech comes, directly or
| indirectly, from a lot of prior capital investment. Trillions
| of dollars over the decades, and a sizeable portion of those
| outflows are into developer salaries.
|
| Any trillion dollar capital outlay will invariably measure
| performance, irrespective of the motivations of sector's
| people.
| 28304283409234 wrote:
| > Any trillion dollar capital outlay will invariably measure
| performance, irrespective of the motivations of sector's
| people.
|
| Yes. And that is a Bad Thing. That kills joy and wonder.
| jmorenoamor wrote:
| Proper tools Proper environment
|
| For me, it's zero friction from problem solving to actual running
| code.
| nine_zeros wrote:
| This. Every manager should measure how much time it takes from
| pushing a commit to code review to CI to staging to production
| to feature flags enabling to rollback time.
|
| Every single stage of this can be a flaky system, adding
| unnecessary toil on engineers. And your reports are not paid to
| fix all the toil.
|
| Management should figure this out and bring it up to relevant
| teams to solve these issues before asking engineers to "do it
| faster"
| saqadri wrote:
| I wish the "how much an engineer can focus" section was first,
| because that's been by far the biggest bottleneck in most
| organizations in my experience.
|
| All the other things the engineers can themselves address (e.g.
| better tooling, etc), but the organization's culture around
| protecting makers schedule is impossible to address individually
| someweirdperson wrote:
| > All the other things the engineers can themselves address
| (e.g. better tooling, etc)
|
| Everyone choosing their own tools? Isn't there usually some
| central department that takes care about that, at best
| controlled by a kind of committee representing those who use
| the tools, typically full of people who are no longer doing
| practical work and have no idea what improvements have been
| made outside of the company during the last decades?
| 0xEFF wrote:
| No, the best organizations have a happy path laid out for org
| chosen tools and a platform that supports adding in "non
| standard" tools / libraries by individuals and teams as
| needed, with a defined path toward those additions become the
| new golden path standard.
| svilen_dobrev wrote:
| somehow the (developer's) Fun is always left out of the
| functionality--time--price race. All them things in the article -
| yes, but if it's no fun (even little) working all that, wontdo.
|
| And the definition of fun can be elastic, but.. it has to be
| there.
| roandepoan wrote:
| ChatGPT
| add-sub-mul-div wrote:
| If you think that's productivity, wait until you have enough
| experience that you can do the vast majority of your work
| without stopping to rely on an outside system at all.
| dboreham wrote:
| Doors. No meetings.
| lordnacho wrote:
| I don't think the obvious things really help though. Whether a
| compile takes 5 minutes or 10 minutes, you are still going to
| async out of it and do other things. You might not come back to
| it until well after, eg at 15 or 30 minutes. If the same compile
| only took 10s though, you would stare at the screen and then get
| to testing immediately. So it's definitely non-linear in the
| sense that it would be great if it were super fast but if it's
| already slow, being a little slower doesn't harm much. With all
| the tooling, there's a distinction between fast enough to use
| synchronously and so slow that you need a reminder to come check
| the results.
|
| IMO the thing that really matters is domain knowledge, a fancy
| way of saying judgement. If you know your domain you might avoid
| the most expensive mistakes: having to change language or
| framework, requiring entirely different developers, bricking
| hardware that you paid a lot of money for, buying services that
| you don't need, writing code that won't be used.
|
| Another thing I'd mention is having people to bounce ideas off.
| LLMs are actually ok at this, in the sense of spitting out lists
| of things that you might have missed. But in general having
| another expert around to really discuss stuff saves a lot of time
| going down caves that you forgot not to go down.
| meesles wrote:
| Hey everyone, this isn't an Ask HN. There's an article with many
| of the points to discuss:
|
| Knowing what to build, Doing fewer things, Tooling that reacts
| quickly, Knowledge in the developer's head, etc.
| JTyQZSnP3cQGa8B wrote:
| Can we discuss the fact that he forgot to mention that "having
| a good manager" makes people happy and productive? Because it's
| IMHO the most important thing that can make or break a good
| developer.
|
| The whole article only mentions topics that developers can fix
| themselves, not stuff that we cannot change and are very
| important in the daily work.
| TheAceOfHearts wrote:
| The real answer for a large number of software engineers is
| amphetamines and other stimulants.
| doubleunplussed wrote:
| Yep. I just got diagnosed recently. Still figuring out the
| right dose of the right meds, but in the meantime it has become
| painfully obvious that a lot of discussion around productivity
| and procrastination is happening without a lot of people
| realising they may simply have ADHD. There's a reason
| psychiatrists treat ADHD with medication first rather than
| trying to get you to follow productivity hacks or change your
| habits. Would have been good if ADHD was on my radar as a
| possibility much earlier.
| baus wrote:
| As a manager I'm going to throw in some more "fuzzy" ideas --
| shared purpose and team identity. Also recognition of milestones
| and accomplishments
| hkon wrote:
| Care to elaborate?
| nathants wrote:
| a decent laboratory, health, curiosity, and joy.
| dgant wrote:
| The easiest way to be unproductive is to make something nobody
| wants. I've seen a lot of dev time spent on products where nobody
| bothered to validate their need at much less expense.
| synergy20 wrote:
| To me it's not about management or whatever, it's about profit
| sharing.
|
| If my productivity will eventually turn into profit that I can
| get by some bonus or rewards sharing, I will figure out so many
| ways to boost my productivity instead of waiting for a group of
| MBAs to figure out how to do the optimal KPI on me.
|
| HR: What's your dream about your job here?
|
| Me: My dream is to earn enough so I do not need work here(by the
| way, most likely that means the company will also be successful)
| justrealist wrote:
| Why don't you just join a startup as engineer < 5?
| calderwoodra wrote:
| Even better would be a later stage startup (series C/D/E).
| Employee #1000 at Facebook, Square, Twitter (and many others)
| have probably done pretty well for themselves financially.
| Plus startup valuations are at multi-year lows right now.
| justrealist wrote:
| The point is that it's hit-or-miss whether you're
| compensated commensurate with your impact at a C/D/E
| startup.
| gv83 wrote:
| given my current reality ~ an obscene company that marketed
| itself as super tech driven then it's just a bunch of operations
| people with a phone and a shared excel file that reject every
| effort to be automatized ~ the first and last list item hit very
| close to home as in what is sapping my energy.
|
| it's incredibly discomforting to spend even 10 minutes building
| things the other party clearly doesn't want, but since everyone
| is a bloody "head" or "chief" of something, no one ever clearly
| defined upstream-downstream relations between teams. There is a
| lot of infighting and parleying over everything.
|
| for the same reason, we switch gears mostly every 90 days, and
| most of the code has been written by some very junior programmers
| that never deleted any now unused feature and spaghettized
| everything (every 1-n relation has the fk on the wrong side lol).
| the PO is also a nice guy but absolutely incompetent at
| navigating this particular org, as suffers from the hero syndrome
| and wants to save the company.
|
| the pay is decent (for where I live at least; it's a /10 from the
| "500k tc/1 yoy" reality of usa, and i have like 10 YoY, even if I
| worked in very modest places so not many big challenges), and i'm
| changing house in a couple of months. Thanks to idiotic local
| policies the furniture+building materials prices skyrocketed
| (literally 2-5x). This is literally the last bit of motivation I
| have and I'm counting the days until I can finally let go of
| those cretins, even if I have to stay a couple months without
| work.
| black_13 wrote:
| [dead]
| siliconc0w wrote:
| Business leadership is technical, they create the requirements
| with technical leaders, those leaders build out the roadmap. I
| don't believe in 'agile' but I think 4-6week chunks of work
| broken off and worked on by a small team (2-4 people) works well.
| I like to see small design doc to ensure open questions are
| ironed out that gets signed off on by stakeholders - everyone
| should be committed on the vision and these signoff should happen
| relatively quickly, ideally comments resolved and go/no-go
| decision within a week.
|
| The small team should have a lot of support in terms of an
| infrastructure platform, strong culture and tooling for
| development/testing, project management set up for them, an
| escalation path and check-ins where they can raise blockers.
| There is a template but essentially the small team is left to
| work how they want to work.
|
| After the 'chunk' is delivered, there is a week of wrap up, and
| then a week of maintenance where people are allowed to work on
| whatever they think is the most pressing issue.
| BiteCode_dev wrote:
| You don't believe in agile, but yet whole your comment is
| basically what agile is supposed to be.
|
| So I'm going to say you have seen corporation bastardization of
| agile and rejected it, which is a good thing.
| tansan wrote:
| I'm inclined to believe proper agile is a myth. I have never
| seen it done correctly, and it's always spoken about ideally.
| All forms of agile I have seen or heard about always breaks
| down in real businesses environments.
| mpweiher wrote:
| > I'm inclined to believe proper agile is a myth.
|
| It's not.
|
| > I have never seen it done correctly
|
| I have. And it wasn't hard. In fact, it seemed entirely
| effortless at the time.
|
| https://news.ycombinator.com/item?id=36727366
|
| The Agile Industrial Complex is a horror show, but that
| doesn't mean it's not possible to do agile well.
|
| There absolutely is a way of doing agile well, I've been
| involved in a number of teams that did. And it worked
| extremely well. In fact, we did agile way before the agile
| manifesto came out, and before I was aware of there being a
| name for the things we were doing. We were just doing them
| because they make sense, they make us go fast and they let
| us have fun while doing it. Which is basically what the XP
| people said when they started writing things down. They
| never claimed to have invented a brand new way of creating
| software. No, they were observing that certain teams were
| very productive, and looked at what those teams were doing.
| If there was a pattern. Spoiler: there was.
|
| Anyway, I also introduced agile "practices" in a large
| company. Well, in a small team in a large company. We
| didn't do a single one of the practices the Agile
| Industrial Complex proposes and often mandates. The much
| more important team next to us did. They did all the AIC
| practices. We did the technical. And interacted closely.
| Did TDD, worked on trunk, paired when necessary, did stuff
| alone when not. Did the simplest thing that could possible
| work. ("Where's your database?" "We'll put it in when we
| need it". <later> "Oh we're done. I guess we didn't need
| the database -\\_(tsu)_/-" ).
|
| The more important team next to us that was doing Scrum
| with the standups and whathaveyounot failed. We delivered.
| Hmm.
|
| And if you can point to the practices being promoted by the
| AIC as being in direct and obvious conflict with, for
| example, what's written the Agile Manifesto, and can in
| fact point to ways of doing it right that are in harmony
| with the AM and in conflict with the AIC, then it ain't a
| No True Scotsman fallacy. It's a simple case of the AIC
| doing it wrong.
| SkyPuncher wrote:
| I too have seen great agile. However, it required the
| team to be in control of its own destiny. Namely, we
| didn't have deadlines and the goals we reported against
| were impact. That meant we could run no-weekly sprints
| while safely fitting delivery into the goal reporting
| timetable.
|
| In most companies, it seems management is incapable of
| measuring progress other than "will X be done before Y
| date".
| mpweiher wrote:
| > I too have seen great agile
|
| Awesome. It _is_ a sight to behold and experience to
| savour.
|
| > it required the team to be in control of its own
| destiny
|
| Absolutely. If only someone had written this down. What a
| missed opportunity!
|
| "The best architectures, requirements, and designs emerge
| from self-organizing teams."
|
| https://agilemanifesto.org/principles.html
|
| > goal reporting timetable.
|
| "Responding to change over following a plan"
| gv83 wrote:
| same for the legendary "maintainable/evolvable/perfectly
| encapsulated code". yes, until the team is very skilled,
| everyone is disciplined and there are tight processes
| around learning the architecture. 3 bad hires later because
| "investors want growth!!1" and you're done :D
| mpweiher wrote:
| > are tight processes around learning the architecture.
|
| Yep. Because we currently don't have any way of clearly,
| concisely and obviously expressing the architecture in
| the code.
|
| https://2020.programming-
| conference.org/details/salon-2020-p...
|
| What if we could?
|
| https://objective.st/
| gv83 wrote:
| cool links, thanks for sharing. I also share your
| feelings, but reality (or burnout) is starting to take
| its toll on me and I see too much uninterested people
| working as SWEs nowadays. I mean, tooling is probably
| part of the problem, but quality is going downhill real
| fast, with people with 2/3 years on the job not
| understanding simple things like HexArch or basic
| patterns (not advocating for anything, just mentioning
| something that should be common knowledge in 2023).
|
| I'm starting to think that if we want to maintain this
| "race to the bottom" pace, we need a more
| industrialized/blue collar approach and be more less
| about the person and more about the tool. Most jobs in my
| area are web crud controlling a transaction script. there
| is no problem to solve.
| Silhouette wrote:
| _I mean, tooling is probably part of the problem, but
| quality is going downhill real fast, with people with 2
| /3 years on the job not understanding simple things_
|
| I agree but I also wonder why we would expect them to.
|
| Many coming into the industry have had little formal
| education in CS or SE. Employers providing substantial
| training is mostly a thing of the past because retention
| and professional development for employees has mostly
| been deprecated in favour of the rapid job-hopping
| culture. And for a while now it's been such an employee's
| market that developers haven't needed to invest their own
| time and money into professional development in order to
| progress their careers.
|
| So even for relatively senior devs it's easily possible
| that they could have little academic education, little
| professional training provided by any of their employers,
| and little incentive to spend their own time studying.
| Their understanding might come from nothing but a few
| years of experience working on only 2 or 3 different
| products and - if they're lucky - some ideas they've been
| exposed to through more experienced mentors, team leads
| and code reviewers.
|
| I personally believe our industry would be infinitely
| better if we could get back to the idea that professional
| development is important and employers should both look
| for people who've been learning and then support their
| people's ongoing learning themselves. Maybe we can even
| do that now that the gold rush is over and job-hopping
| every five minutes for a pay and title bump is no longer
| the most reliable way to climb the career ladder.
| palata wrote:
| I like the original Agile principles:
| https://agilemanifesto.org/principles.html.
|
| Now it has been abused to create a whole business with
| bullshit "agile coaches" who sell agile "bibles" and teach
| cargo cult.
| 6D794163636F756 wrote:
| It's funny to me just how counter to the agile manifesto
| tenets agile coaches tend to be
| aleph_minus_one wrote:
| > It's funny to me just how counter to the agile
| manifesto tenets agile coaches tend to be
|
| Well, this strongly evidences that these agile coaches
| are fraudsters who don't know the elementary basics of
| their specialist field ... ;-)
| jack_riminton wrote:
| I'm adding that to my list of corporate tech paradoxes
|
| It joins: - Innovation departments being built the least
| innovative departments you'll ever meet - HR departments
| being the worst at dealing with people
| 6D794163636F756 wrote:
| Agile as a noun is a myth. Agile as an adjective is a
| journey. When I've seen a company being agile and
| responding to change it's not because they are using some
| system they learned at a seminar, it's because they trust
| their engineers to do the technical work, trust their
| product people to have solid relationships with customers,
| and empower both groups both in their individual roles and
| when communicating with each other.
|
| All of this is to say that I agree with you. 'Agile
| Methodologies' are a crutch for companies that cannot
| tolerate agility
| siliconc0w wrote:
| The key differences from the most common implementation of
| agile are bigger delivered chunks, multiple sets of smaller
| self driven teams, no highly prescriptive ways of working,
| and avoiding constant 'sprinting' with at least two weeks
| dedicated to bug fixing, maintenance, and retros/self
| improvement between 'sprints'.
| mighmi wrote:
| Very detailed design documents can also be lovely. I've
| personally worked at a few organizations where expected
| behavior was ironed out before we started building it.
| (Banking, Engineering etc. will be used to decision flows, so
| this can be common.) The Million Man Month covers the
| effectiveness of good schematics.
|
| However the technical people needed to work them out with
| stakeholders can be expensive to have fight with stakeholders
| for ages, so it tends to be rare. And of course many domains
| are unknown, so you just keep reiterating until something
| sticks.
|
| Modern agile sucks, but if you read the old discussions on
| c2.com of how agile appeared e.g.
| https://wiki.c2.com/?AgileProcesses there really is a lot of
| value to find, learn and apply. Of course, the ninjas,
| blackbelts and cargoculters kill that.
| amelius wrote:
| I wouldn't be surprised if the majority of HN readers doesn't
| even know what a good requirements document looks like.
| galoisscobi wrote:
| Business leadership being technical cannot be overstated. At my
| current workplace, we're not allowed to say the word refactor
| to management as that freaks them out. My current place also
| has the most spaghetti code that I've ever seen in my life with
| more spaghetti being produced on a daily basis.
|
| We technically have technical leaders, they used to be
| engineers eons ago but I don't think any of them could solve
| first 3 days of advent of code to save their lives.
| cbcoutinho wrote:
| The six week cycle with down time in between chunks can be very
| effective. The crux is to make sure those blocks are properly
| scoped to make the best use of everyone's time.
|
| This reminds me of the excellent book 'Shape up' by the team
| from Basecamp. They also champion upfront 'scoping' to make
| best use of those six weeks. Highly inspirational book for
| technically mature organizations.
| malux85 wrote:
| The week of wrap up and the week of maintenance is _so_
| important, and has basically never been there at places I have
| worked.
|
| Managers reading this - if you constantly jump from new
| features to new features you will ensure that your developers
| are forced to cut corners, make an unmaintainable mess,
| increase bugs, development velocity will slow and developers
| will burn out.
|
| It also causes incentive alignment problems, if I push myself
| to deliver great quality on-time, and I'm striving and working
| hard, then I don't get so much as a "well done" and then an
| immediate enormous chunk of new work - you're rewarding hard
| work and quality with large amounts more work, what's my
| incentive to perform? Exhaustion?
| perpil wrote:
| Instead of building tooling that reacts quickly, the approach I
| take is make it dead simple to build tools in the moment right
| into your documentation using markdown. If building the tool is
| little more than taking the command line you just ran and pasting
| it into the documentation, it's fun to fix things and your
| teammates can instantly do what you did with a click. See it in
| action here: https://godspeed.run
| tekkk wrote:
| I think majority of software development productivity problems
| come down to communication. Either you both can say whats wrong
| or theres a weird little dance everytime something needs to be
| delivered.
|
| Having a bunch of go-to guidelines is nice but really, you all
| just have to be on the same page whats the current state and to
| be able to say honestly whats going wrong when it happens.
|
| Treating developers as monkeys who'll do as dictated doesnt
| really sit well for many of them.
| anotherhue wrote:
| > It's frustrating to hear the statements "you must use our
| infrastructure" and "you can't do that with our infrastructure."
| You waste time either working around the infrastructure or
| sitting in meetings where you attempt to convince the owners of
| the infrastructure to meet your needs.
|
| Listen, I'm an infra guy, so maybe this hit a nerve, but
| 'othering' infra because it's inconvenient has got to stop. Infra
| serves many masters and you are probably the most flexible of
| them -- that's why there's so much push back.
| anotherhue wrote:
| And I will nuke your off-books deployments from orbit.
| comprev wrote:
| I'm involved in implementing some big changes where I work
| and one of them is CI runner-only deployments.
|
| Both infrastructure and applications will follow the same
| workflow - all changes via pull/merge requests, Jira
| integration, etc.
|
| Developers won't have the ability to create resources outside
| of the CI platform.
| candiddevmike wrote:
| I really hope you sold the devs on this instead of
| commanding them to use it, otherwise their director will
| use his credit card to sign up for their own AWS account.
| MattPalmer1086 wrote:
| And that director would be fired as soon as this was
| discovered. At least where I work, but we are heavily
| regulated.
| comprev wrote:
| This would likely be the same outcome. We're implementing
| changes because an outside entity states we require them.
| comprev wrote:
| It's a regulated environment which needed locking down.
| The developers still have access to the same resources
| albeit in a more controlled process.
|
| It's not like we flicked a switch overnight - that would
| be insane - it's a large scale cloud migration project
| over many years.
| anotherhue wrote:
| I've seen many cases where someone signs up for a free
| trial at PaaS-du-jour and then starts pointing prod HTTP
| traffic at mycorp.magicpaas.com
| comprev wrote:
| I've also seen it plenty of times in the startup world.
|
| Unfortunately I've also been involved in the emergency
| bandage fix once it was discovered...
| Silhouette wrote:
| Through the forcefield of a VP two levels above your boss who
| authorised it? Even if you know about it - which is a big
| "if" - you probably won't have either the authority or the
| practical means to shut it down.
|
| It's become a classic problem. Organisations want to
| centralise infrastructure and services because consolidation
| saves on costs and increases visibility and control.
| Particularly if you're under specific regulations that can
| make things much easier.
|
| But that only happens if the centralised provision actually
| works. It has to be adequately resourced and reasonably well
| managed and supportive of the people using the infrastructure
| or services it provides.
|
| If the centralised provision is not good then it had one job
| and failed to do it. Whose fault it is doesn't really matter.
| It's not supporting the other parts of the organisation to do
| their jobs and inevitably a point will come where that infra
| gets "othered".
|
| We've been seeing this phenomenon ever since we had central
| system administrators who could lock down the OS on
| individual employees' workstations. The admins argue that
| they need to make sure security updates are properly deployed
| and they need to prevent non-expert users from breaking
| things and they need to ensure consistency because they're
| also running the help desk and ultimately they're responsible
| for these things so they need the authority to control them.
| All very fair and reasonable. And all completely irrelevant
| to someone with actual revenue-generating work to do who is
| being blocked for days or weeks because some sysadmin whose
| opinions are not necessarily justified by their effectiveness
| hasn't enabled or authorised some essential facility.
| candiddevmike wrote:
| IMO... infra teams need to realize that folks "othering" their
| infrastructure means the infra team isn't meeting their needs.
| Infra teams are now competing against DIY and PaaS solutions,
| especially all of the fly by night YC startups. Infra teams
| need to prove their worth or get out of the way and let the
| devs go buy a solution that replaces the infra team. The
| business cares about time to market, not the perfect little
| homegrown PaaS the infra team built.
|
| For the record, I'm an infrastructure person.
| drewbug01 wrote:
| > Infra teams need to prove their worth or get out of the way
|
| This is an incredibly demeaning comment. Assuming your
| colleagues have inherent worth and that they're doing their
| jobs reasonably given the constraints and demands placed upon
| them is a far more humane way to go about work.
|
| > The business cares about time to market, not the perfect
| little homegrown PaaS the infra team built.
|
| Those "perfect little homegrown PaaS" solutions get built for
| a reason - because of what happens _after_ you get to market:
| the business starts to care a whole lot about how much it
| costs to run the thing you just shipped.
|
| One of the main reasons a "perfect little homegrown PaaS"
| gets built is because it's typically a lot cheaper to run in-
| house. Lots of downsides to it, for sure, but you can't
| neglect the immense cost of a PaaS when you're running a
| business.
| bheadmaster wrote:
| > Assuming your colleagues have inherent worth
|
| That sounds cute, but humans don't have inherent worth in a
| business. If you don't contribute to success (and aren't
| good enough at deceiving people that you are), you're going
| to get laid off.
|
| I think that's what the parent comment is saying - infra is
| competing with potentially cheaper and more flexible
| solutions. Even if they do their jobs the best they can,
| put 100% effort in, yada yada yada - if there's a more
| efficient solution, infra as a whole will be left behind.
| mighmi wrote:
| > infra is competing with potentially cheaper
|
| For example? The managed or cloud or... solutions are
| normally magnitudes more expensive than in house. PaaS
| are the closest in cost, due to the admin savings etc.
| but even there, we know current prices are investor
| funded to gain share.
|
| At the far end, compare what you can get for $150/month
| at Hetzner vs. AWS. At real scale, paying for an infra
| team to run it will save a lot of money (and I've yet to
| see a fully managed solution which doesn't have a team of
| YAMLers anyway.)
| 0xEFF wrote:
| There are loads of startups offering platforms as a
| service for about half the cost per year of one devops
| engineer.
| boondoggle16 wrote:
| Artisan t-shirt makers have inherent worth too... doesn't
| mean we employ an artisan t-shirt maker for every 4
| employees.
| anotherhue wrote:
| 100% this. If your company can run on a managed platform then
| it should. The reasons the whole world isn't already include:
| GDPR, SOC2 (audit, role level responsibilities), customer
| firewalls, encryption requirements (hello FIPS).
| MobileVet wrote:
| 100% part 2. Infrastructure has SO many potholes and edge
| cases. Tackling it directly by 'rolling your own' is
| optimistic naivety at best.
| echelon wrote:
| Managed platforms are obscenely expensive.
|
| I know, I know - "time to market", "scaling on demand",
| "open source isn't free", "not our core competency", etc.
|
| Infra staffing, hardware, scaling, and upgrades are
| expensive. But it doesn't help the fact that cloud costs an
| arm and a leg too.
|
| I can't believe we haven't seen more of a race to the
| bottom in terms of costs and offerings.
|
| Amazon is gorging itself on your margin. I wish we lived in
| a world with 20 AWSes, all at the same scale and market
| penetration.
| MobileVet wrote:
| I don't agree. People are far more expensive than managed
| infrastructure and that is what the comparison should
| be... not against 'bare metal.' When you compare the
| managed infra costs to bare metal directly, you are
| comparing apples to oranges.
|
| We run an 8 figure business on mid 5 figure managed infra
| costs. An infrastructure team would be several multiples
| more expensive than that... even if it was a single
| individual.
|
| Just because you can do it yourself or more cheaply,
| doesn't mean the effective business costs are less.
|
| Edited: for grammar
| tester756 wrote:
| >People are far more expensive than managed
| infrastructure and that is what the comparison should
| be... not against 'bare metal.' When you compare the
| managed infra costs to bare metal directly, you are
| comparing apples to oranges.
|
| Clearly, because "DevOps" people / skills are for free
| right?
|
| Good software engineers who additionally have exp with
| Cloud and all its craziness definitely aren't asking for
| way higher salaries?
|
| I've worked in small size data center and the amount of
| work performed by 2x minimal wage technicians was huge.
|
| They were running on 5-10 engineers + 3 more skilled ppl
| at day and 1 person on night shift with 1 or 2 being
| "wakeable"
| anotherhue wrote:
| Just to be clear, I never mentioned costs as a factor.
| Those are about margin, what I'm discussing is about core
| product.
|
| "Is a product made by grown ups familiar with your
| sector" is an actual selling point for most enterprise
| SaaS.
| jayd16 wrote:
| Very true. I realize infra teams have their own priorities
| but all too often I meet infra folks that would rather tell
| me my requirements are wrong than work with me towards a
| solution. If you're not getting better customization from the
| inhouse team then it's not hard to see a big paas is probably
| a better offering than what the infra team deems necessary.
| oldtimerherez wrote:
| It's definitely not the endless hierarchy of interfaces, abstract
| classes and abstractions, etc. There is such a thing as cognitive
| overload and time spent to get to a goal. If I have to look at
| more than 3 files to know what is going on, maybe push it to 5.
| Then I know this project is a time sink. Let alone all the
| magicry to just get to Javascript in the browser. I miss the good
| old days. Where discipline was part of a developers mind and
| lazyness was not heralded as a panacea.
| CoastalCoder wrote:
| Purpose.
|
| If I feel like there's a small chance of my commit being
| accepted, or ever mattering, it's hard to fake the motivation to
| work on it.
| nine_zeros wrote:
| Your purpose is to serve the code reviewer, manager, and execs
| so that they can achieve their career and monetary goals.
| cyb_ wrote:
| Have you talked with the reviewers about this?
|
| When I've seen this happen it usually boils down to
| communication problems. The solution is often to talk to the
| reviewers _before_ writing the PR.
|
| For example,
|
| 1. Disagreement about the problem/solution - hash out the
| design first, then write the code
|
| 2. Disagreement about priorities - align expectations before
| investing too much time in design or code
|
| 3. (etc)
|
| Yes, communication is hard. Unfortunately, it's really the only
| way to get things done with other people. Building decent
| communication skills is a worthwhile investment for all SWEs
| zer8k wrote:
| Piggybacking this to say I will never be extremely productive
| when all my job boils down to is shifting code from one place
| to another, or building yet another braindead CRUD endpoint. My
| mind begins to wander and think about other things. I hear a
| lot of "we want to use our engineers in the best way possible"
| only to put people on mind-numbing zero-thinking framework
| guided work that doesnt capitalize on any of the traits of a
| good engineer. Before the frothing at the mouth business-minded
| people start saying "creative engineers are dangerous" I would
| suggest you actually go talk to your engineers. I doubt they
| say they want to greenfield a production idea in haskell. What
| they want is something that isn't the programming equivalent of
| a box ticking TPS report.
| vsareto wrote:
| These are jobs where you want to be good enough to autopilot
| through the work quickly then fuck off and do whatever for
| the remaining 80% of the sprint. It's absolutely a dead end
| for anyone who wants to experience the 'craft' spirit of
| software.
|
| If you're feeling particularly bold, you can hold two of
| these jobs and do something unheard of in recent times:
| actually being able to save for a decent retirement.
| codingdave wrote:
| > it is advantageous to minimize how often ownership changes
| hands - no one will ever know more about a thing than the person
| who created it.
|
| This may be true when looking at a single individual, but this is
| exactly how teams get locked into the bus factor of 1. The person
| who creates a codebase needs to train others on their knowledge,
| so the entire team has that understanding that allows them to be
| productive. The slowdown to train someone up to know as much as
| the creator is quickly paid off when 2 people know the codebase.
| And it scales more with each new person because not only do more
| people know it, but the knowledge transfer gets streamlined and
| the confusing parts of the app are identified and fixed.
| Trasmatta wrote:
| I've begun to feel like we might put too much value in the "bus
| factor". Many companies have de-emphasized specialization in
| order to "spread knowledge and context". I think that's
| resulted in worse job satisfaction and developers who are
| spread too thin.
|
| Not to say every person should have a silo-ed portion of the
| codebase that nobody else ever touches or understands. I just
| think the pendulum has swung too far in the other direction.
| Silhouette wrote:
| _Not to say every person should have a silo-ed portion of the
| codebase that nobody else ever touches or understands. I just
| think the pendulum has swung too far in the other direction._
|
| Yes. It's one of those mythical management "best practices"
| that never actually happens because it doesn't work.
|
| Most interesting software development involves creative
| thinking. Unless someone finds a way to download the entire
| thought process of the original developers and losslessly
| transfer it to other developers later you can't recreate 100%
| of the knowledge and insights that came from the original
| development work.
|
| What you can do is acknowledge that your developers are
| individuals with unique knowledge and abilities not just in
| general but because of their history within your own
| organisation. Value the unique experience they collect while
| working with you and - for as long as they remain with the
| organisation - encourage them to actively support colleagues
| who are later working in the same part of the code.
|
| There is no substitute for retaining that knowledge and
| having the original source directly accessible but of course
| most people do move on eventually. So it's also a good idea
| to emphasise good design and coding and documentation
| practices so that even when the original developers move on
| and you'll never have access to the ideal source of knowledge
| again you still have enough to figure things out when you
| need to. The fallacy is the idea that working that way will
| ever be comparable in productivity to having the original
| source still around and willing to help.
| Trasmatta wrote:
| So well put. I think one of the sources of burnout for many
| developers is the complete lack of acknowledgement of the
| creative aspect of programming in modern development
| processes.
| astockwell wrote:
| I'm curious what others have experience here, as a code base
| grows.
|
| I've been on several teams that consistently endeavor to keep
| the knowledge of a code base shared, but every time the code
| base reaches a certain size, the Bus Factor creeps right back
| in, but this time for "modules" or areas of the broader code
| base.
|
| Combine a large code base, 4-8 engineers making constant
| changes all over, and it becomes a real struggle to keep
| everyone "up" on the whole thing.
|
| Has anyone seen a workable strategy for this?
| add-sub-mul-div wrote:
| Making sure someone has enough knowledge to cover an area:
| giving a man a fish.
|
| Encouraging the mindset to be able/willing to learn new areas
| as needed: teaching a man to fish.
| pipeline_peak wrote:
| Getting something to work well enough today as quickly as
| possible so you can move onto the next ticket...... :(
___________________________________________________________________
(page generated 2023-07-16 23:01 UTC)