[HN Gopher] A dev's thoughts on developer productivity
___________________________________________________________________
A dev's thoughts on developer productivity
Author : raviparikh
Score : 80 points
Date : 2022-05-17 18:33 UTC (4 hours ago)
(HTM) web link (about.sourcegraph.com)
(TXT) w3m dump (about.sourcegraph.com)
| Kranar wrote:
| >Most self-styled experts on developer productivity seem more
| interested in selling something rather than painting an accurate
| picture of how devs really work.
|
| Says a blog post from a CTO who sells a product to track software
| productivity.
| slimsag wrote:
| (I'm an engineer at Sourcegraph, but otherwise share your
| healthy skepticism of companies in general)
|
| For what it's worth, I don't think that's accurate. I've worked
| closely with the team that builds Code Insights, and at pretty
| much every point they've been vehemently opposed to exposing
| any metrics that could ever be used to track/monitor devs.
|
| On the contrary I've actually heard most use cases of it in
| companies are actually devs themselves showing
| leadership/management clear graphs of "look, code quality here
| is getting worse, we need more time in sprints to improve this"
|
| Anyway, just my take, not commenting in any official capacity.
| johnnymorgan wrote:
| Blend that in with some product intelligence to manage
| stackholders and booya, a solid nice product/dev integration.
|
| Quality of user stories and product cycle would be
| interesting to see as it has a direct impact on dev quality
| (ie how much do they have to guess versus cleanly mapped
| out).
|
| It's pretty cool and I see where you are going with it.
| beliu wrote:
| Sourcegraph CTO (and author of the post) here. There's no part
| of our product that seeks to track software productivity?
|
| We do have a feature (https://about.sourcegraph.com/code-
| insights) built around code search that lets devs define their
| own metrics around things like progress of big migrations and
| anti-patterns + code smells. This tweet is a good summary of my
| philosophy around code-related metrics:
| https://twitter.com/beyang/status/1524259425451577344.
|
| Insights from treating code as data are best discovered by the
| people who know the dataset through and through--i.e.,
| developers. Another project we've released in this vein is
| https://codestat.dev, built on top of Comby (incidentally also
| on the HN front page right now), which was created by a member
| of our team, Rijnard, as part of his PhD thesis on automatic
| program transformation.
|
| We're developers by trade and by heart, and are motivated by
| making tools and mental models that devs actually find useful
| and that boost the creative spark of coding. If there's
| something we can improve about our product or message to
| further this mission, I'd love to hear your feedback!
| kodah wrote:
| I think you're getting some snark because corporations are
| firing up a renewed interest in these kinds of metrics and as
| part of that they're starting with all the old ones (and
| motivations) that didn't work. Your messaging was fine, and
| your product has a clear audience (developers), this is just
| the fallout of industry bad behavior.
| beliu wrote:
| This is really important to call out. There have been a lot
| of really bad practices in the past that try to reduce
| "developer productivity" to something that approximates a
| widget factory, and the results have been awful for both
| developers and companies. This feeds right into the last
| section of the post, "If we don't talk about developer
| productivity, someone else will"--we need more developer
| voices advocating for the creative spark of building
| software.
| dnndev wrote:
| What is your product for me as a developer?
| beliu wrote:
| World's best code search: https://sourcegraph.com/search
| Analyze code as data: https://sourcegraph.com/insights
| Interactive docs you'll actually use:
| https://sourcegraph.com/notebooks Take the pain out of
| large-scale refactors: https://sourcegraph.com/batch-
| changes IDE superpowers in code reviews:
| https://docs.sourcegraph.com/integration/browser_extension
| dnndev wrote:
| Thanks for the links. Looks like a nice utility belt for
| devs who want to be productive.
|
| Most orgs kill productivity and creativity with lack of
| compensation, treating them like a code farm, or mediocre
| peers.
|
| Devs choose to be productive in different environments,
| most of the time it's simple, step aside and let the dev
| do more than code. Talk to a client (yes! It's not as
| crazy as it sounds). Show appreciation with bonuses not a
| seasonal holiday themed ham.
|
| I think your headed in the right direction!
| TameAntelope wrote:
| This isn't super related, but the unexpected complication I've
| run into as I've tried to scale my team is that nobody has the
| knowledge I have, so I've got to spend most of my time showing
| folks how to do the work.
|
| The problem here is that if I'm not being productive (I'm
| teaching), and the other devs are not being productive (they
| don't know the domain), then nobody is productive.
|
| You'd think that'd level out eventually as the other devs grow,
| but on short runways, there really isn't time for that.
|
| However, we can't hire devs who know the domain because a)
| they're not looking for jobs and b) the ones who are we can't
| afford.
|
| So it's just me, teaching other devs, when I could/should be
| pounding out code so we can get a few more sales, which will
| justify the next round.
|
| Unintuitively, it probably didn't make sense to hire anyone else,
| but that feels weird because then it's just me in a dark room
| churning out code nobody's reviewed, and there really is plenty
| of work to do, it's just all work only I seem to be able to do.
|
| I assume this is standard for early stage startups who haven't
| yet found their P/M fit, but it is odd.
| goncaloo wrote:
| Great article!
|
| > What good is "change failure rate" if you can't even jump-to-
| def across your code?
|
| Exactly. Organizations often focus on the externally visible
| factors without considering the day-to-day of a developer
| productivity. If only we spent more time to refactor/maintain and
| general tooling instead of more status updates and unnecessary
| processes, imagine the productivity we could achieve..
|
| At Google we had this simple problem yet it halted our entire
| team's productivity: IntelliJ started being insanely slow
| indexing files and auto completing stuff. It was a mixture of
| generated code and the monorepo that made it take tens of seconds
| for any kind of autocompletion. It's been there for years but
| there wasn't much priority to fix it, so things kept going (and
| probably still keep going) like this...
| zarkov99 wrote:
| Man, I have seen this everywhere, there is so much low hanging
| fruit for organizations that take developer productivity
| seriously. It is insane the amount of friction (leading to
| burnout, disengagement, and ultimately turnover) that
| developers deal with, _every day_ , just because no one in the
| organization can see past their quarterly OKRs and fix basic
| things.
| jrvarela56 wrote:
| It baffles me how everyone complains that they can't find
| talent and that devs make so much money, but at the same time
| don't invest in at least trying making devs 2-5x more
| productive.
| BlargMcLarg wrote:
| The state of the industry could be way, way better. We just
| decided not to do so for.. some reason. We could answer it,
| but every time someone does, they get dogpiled by
| naysayers.
|
| On the other hand, if the industry truly evolved, it would
| probably up the barrier to entry to a level a lot of
| developers would be out of a job.
| marcosdumay wrote:
| Unless we are very close to "peak software" where the
| most valuable problems are already solved (very
| unlikely), raising the productivity of some developers
| will not negatively affect other ones.
| BlargMcLarg wrote:
| I'm fairly certain we'll hit the point where we can no
| longer reasonably throw bootcampers at jobs and expect
| professional output by 3 months way, way before "peak
| software". We already don't expect that from loads of
| other fields, both arts and sciences.
| alasdair_ wrote:
| Stripe has the concept of "paper cuts" that any developer can
| file via a simple web form. These are small annoyances that
| no one will have an OKR for but are bothersome nonetheless.
|
| There is a team that focuses on fixing these smaller issues,
| in addition to a larger dev productivity team that works on
| the more gnarly problems like "building takes too long".
| Importantly, the team DOES have an OKR for fixing paper cuts,
| and gets kudos for doing so.
| tonioab wrote:
| It's great to see deeper pieces about developer productivity - in
| this case starting from first principles and the actual
| experience of developers. The notion of feedback loops has also
| been explored in e.g.
| https://martinfowler.com/articles/developer-effectiveness.ht...
|
| The bad reputation of developer productivity metrics comes from
| the misguided assumption that developers should be measured. The
| better approach is to treat developers as customers of the
| management team / engineering enablement team /etc. In that
| sense, developer productivity is actually a measurement of
| management effectiveness / organizational health.
|
| Once you build your developer productivity approach on this
| basis, what needs to be measured becomes much clearer - for
| example: interruptions caused by meetings, performance of local
| tooling like local builds, latency of CI, number of on-call pages
| triggering outside business hours, etc.
|
| The right set of metrics depends on your team and can be sourced
| from surveys and just talking to people about what's painful on a
| daily basis. As a quick and dirty solution, I'd even recommend
| piping Github webhooks and other events to a product analytics
| tool like Amplitude or Mixpanel. You'd be surprised how fast you
| can understand things like build or CI latency by using a classic
| funnel visualization.
|
| A lot of great engineering teams are migrating to this approach,
| especially when they have a dedicated platform / enablement /
| productivity engineering team.
| ilrwbwrkhv wrote:
| I think a lot of the problems today are with the project
| management tools. Every single tool focuses on the day to day and
| not the big picture. The day to day should be left to individual
| teams. But on a company scale, a nice broad project management
| tool would be something that would be really useful.
| phaedrus wrote:
| After a series of previous employers I ended up burned out (but
| sort of wasn't sure if I was or not). I couldn't quite pin down
| WHAT it was that was burned out of me until I saw this quote from
| the linked article:
|
| "Flow state is that state of focus and productivity that you
| attain when you're feeling inspired and motivated."
|
| ...which makes perfect sense as two of the worst-offenders were
| places where I was expected to put out lots of code requiring
| flow-state, while simultaneously being immediately and constantly
| available to instant messages and email-used-like-instant
| messaging.
|
| The scary part is, the ability to focus and produce like I could
| the first years I was programming never came back. Now, I'm
| working at a place and in a role where my employers seem happy
| with what I'm doing, but _I 'm_ not happy with the rate I (can't)
| produce at.
| cletus wrote:
| IMHO the #1 thing you can do for developer productivity is to
| reduce the development feedback loop to under 30 seconds and
| preferably under 10. Why? Longer than that and you have two
| choices:
|
| 1. Work on simultaneous tasks at once. This incurs a context-
| switching penalty; or
|
| 2. Get distracted by HN, social media, reddit or whatever. This
| has the same context-switching penalty and you can end up
| spending way more time on that distraction than the development
| loop actually needed.
|
| I've worked on a code base where it took 3 minutes minimum to run
| a unit test. Some adjust to this mindset by doing more in a
| single test but even in the most optimal fashion it's not as good
| as quick turnaround.
| pharmakom wrote:
| This is why I love static checking tools such as type systems.
| I often get the feedback as I type.
| cletus wrote:
| I agree 100%.
|
| Compiler errors are strictly superior to runtime errors. It's
| as simple as that.
| dan-robertson wrote:
| Google is famous for having amazing dev tools. If any (large)
| project is going to have this most-important thing, it is
| likely to be best able to get it at Google. And yet Google also
| has a reputation for low developer productivity. So, what
| gives? Are some of my premises wrong, is the most important
| thing not close to sufficient, is Google actually productive?
| jklm wrote:
| Google had amazingly below-average dev tools when I was
| there. It was standard in my org to have multi-minute builds,
| with input/output streamed to/from a remote server. Yes,
| every keystroke had a small but perceptible delay. I was
| working on an outlier project that took over 30 minutes to
| build for a single-character change. I never learned as
| slowly as I did during my time there. Startups generally have
| faster tech, bigcos generally have more customized tech with
| more options and that can operate 'at scale.'
| chrisweekly wrote:
| Awesome post. The pictures -- and the ideas they represent --
| resonate.
| lewisl9029 wrote:
| Really enjoyed the article! Wholeheartedly agree with the use of
| iteration speed as the measure for productivity.
|
| I think one key under-explored opportunity for improving
| productivity involves bringing the outer loop closer to the inner
| loop. The main reason we have a distinction between these loops
| is everything we need to do in the inner loop generally happens
| fast enough to keep us in flow state, while everything in the
| outer loop is usually slow enough to break flow state.
|
| In the graphic illustrating the inner loop vs outer loop in the
| article, only the Plan, Review, Measure, React, steps have
| intrinsic latency floors based on
| product/market/human/organizational constraints. My hypothesis is
| that the other three, Author, Test, Deploy, are constrained in
| latency only by technology, and can be made fast enough keep us
| in flow state given the right technology, bringing them into the
| inner loop.
|
| Disclaimer: My ulterior motive in writing about this is I've been
| building a product to do exactly what I described above, for
| client-side rendered React apps: https://reflame.app/. But I
| would honestly love to see more folks explore opportunities here,
| since I want to be able to build all kinds of software this way,
| not just the kinds I have the bandwidth/skills to work on.
| paulbjensen wrote:
| This was a a really good post.
|
| I work in a large organisation where some of the issues mentioned
| are very relevant, especially the 'flow state" issue.
|
| We have a mix of on-site and remote workers (myself being a
| remote worker), and because Slack/Teams is our primary method of
| communication with colleagues, and I operate in a tech lead role,
| it becomes difficult to achieve flow state on some tasks.
|
| I ended up creating an Apple shortcut that automatically setup
| the computer for operating in a flow state (called Superbam -
| https://www.icloud.com/shortcuts/5c0c729476584e11b3b12744893...).
| It helped to some extent.
|
| I think a lot of organisations are clueless about flow state and
| why they should give developers the chance to reach it.
| gorgoiler wrote:
| The author is very clever. This was a fascinating read.
|
| On the inner loop, and progress being a vector sum: one thing I
| find crucial is knowing where I have to go. That translates to
| two mantra: rush to the finish line, then rebuild it if needed.
|
| When embarking on a project I know roughly what stages are
| needed. Maybe three dependencies, one more to bring them
| together, one more to deliver a subsequent result, and one outer
| one to present the whole code. Example: a web scraper to get
| weather data, a thermometer polling daemon, a database to store
| the two, a scheduler to run the first two and store it in the
| database, and a module to perform high level queries on past data
| and forecast trends for the future.
|
| It's really easy to deep dive on any one of those components.
| It's not until I get to the final one that I realize how little I
| really know about problem. I'll explore it a little, then work on
| something else for a week, then come back and know exactly how to
| retackle the problem from start to finish. It's the revisiting
| that gives me insight into what to do, and it was the rush to
| build the prototype that gave me the raw materials needed to have
| that insight.
|
| All of this requires at least one whole day of concentration,
| then three half days of tinkering, then a final week of rewriting
| and polishing and responding to code review.
|
| So much of this process is subject to external forces that impact
| my productivity. I am grateful to this article for solidifying
| them in writing.
| beliu wrote:
| Author of the post here. This _really_ resonates with me. One
| of the best pieces of advice I 've received in my life as a
| programmer, from my first manager actually, was "focus on
| getting an end-to-end system up and running first, no matter
| how janky, and then refine from there".
| marcosdumay wrote:
| Oh, that's for sure. If you don't know what direction to go,
| you'll get into a random walk, for what the most common outcome
| is to spend all your days moving without getting anywhere.
|
| If instead you rush, you get a longer average free-path and may
| gather enough information from the results to decide a
| direction.
|
| The situation is different if you already know where you are
| going before you start.
| ChrisMarshallNY wrote:
| I've been writing about the way I work for years. I haven't
| bothered to boil things down into a pattern, but the explanations
| are fairly clear:
|
| https://littlegreenviper.com/various/concrete-galoshes/
|
| https://littlegreenviper.com/miscellany/forensic-design-docu...
|
| https://littlegreenviper.com/various/evolutionary-design-spe...
|
| https://littlegreenviper.com/miscellany/thats-not-what-ships...
|
| https://littlegreenviper.com/various/testing-harness-vs-unit...
|
| https://littlegreenviper.com/miscellany/leaving-a-legacy/
|
| https://littlegreenviper.com/miscellany/risky-business/
|
| https://littlegreenviper.com/various/the-road-most-traveled-...
___________________________________________________________________
(page generated 2022-05-17 23:00 UTC)