13 ms·

What makes developers productive?

• deleted 3y ago
  [deleted]
• black_13 3y ago
  [dead]
• jmorenoamor 3y ago
  Proper tools Proper environment For me, it's zero friction from problem solving to actual running code.
  • nine_zeros 3y ago
    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"
• roandepoan 3y ago
  ChatGPT
  • add-sub-mul-div 3y ago
    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 3y ago
  Doors. No meetings.
• BowBun 3y ago
  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 3y ago
    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.
• baus 3y ago
  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 3y ago
    Care to elaborate?
  • deterministic 3y ago
    As a former manager and current developers I say no thanks. Just stay out of the way, protect the team from outside BS, and focus on fixing what the team is annoyed about. Your team will love you for it.
• anotherhue 3y ago
  > 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 3y ago
    And I will nuke your off-books deployments from orbit.
    • comprev 3y ago
      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 3y ago
        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 3y ago
          And that director would be fired as soon as this was discovered. At least where I work, but we are heavily regulated.
          • comprev 3y ago
            This would likely be the same outcome. We're implementing changes because an outside entity states we require them.
• CoastalCoder 3y ago
  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 3y ago
    Your purpose is to serve the code reviewer, manager, and execs so that they can achieve their career and monetary goals.
  • cyb_ 3y ago
    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 3y ago
    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 3y ago
      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 3y ago
  > 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.
  • astockwell 3y ago
    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 3y ago
      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.
  • Trasmatta 3y ago
    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.
• pipeline_peak 3y ago
  Getting something to work well enough today as quickly as possible so you can move onto the next ticket…… :(
• lordnacho 3y ago
  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.
  • physicles 3y ago
    Productivity is absolutely a nonlinear with compile time. I work in Go, so compiling doesn’t take long enough to cause me to async away. Big switch from C++ a couple jobs back where iteration time was measured in minutes.
• 28304283409234 3y ago
  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 3y ago
    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 3y ago
      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?
      • vinyl7 3y ago
        Infinite growth for the shareholders is the only thing that matters these days
        • deleted 3y ago
          [deleted]
      • MildRant 3y ago
        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
• nathell 3y ago
  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.
  • jasfi 3y ago
    I agree, and also physical health too. Poor physical health can lead to poor mental health.
  • egesko 3y ago
    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.
  • duxup 3y ago
    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.
• Joel_Mckay 3y ago
  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_ 3y ago
    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.
    • yesbabyyes 3y ago
      While I agree with the notion, I'm fairly sure this quote is attributed to Blaise Pascal.
      • Joel_Mckay 3y ago
        Meh, all languages including English are recycled isomorphic protocols. Mark Twain was just an alias the author thought sounded engaging... and quoting an alias is like quoting Batman. Incredibly funny, but hardly meaningful... =)
• saqadri 3y ago
  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 3y ago
    > 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 3y ago
      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.
      • bluGill 3y ago
        There needs go be a balance. Common tools are useful, but you need to switch which tool you use from time to time as the old one gets stagnant (or bought out and the new owners raise the price too high). Sometimes people change tools for the wrong reason. I've been in many companies that changed their bug tracker because the old one was too cumbersome, but they never addressed why all those mandatory fields were added to the old one, and so in a few years they learn the hard way and now the new one is cumbersome because of all the mandatory fields.
• TheAceOfHearts 3y ago
  The real answer for a large number of software engineers is amphetamines and other stimulants.
  • doubleunplussed 3y ago
    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.
• dgant 3y ago
  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.
• siliconc0w 3y ago
  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 3y ago
    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 3y ago
      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.
      • electrondood 3y ago
        I've seen agile done extremely well two companies ago, fairly well at my last company, and decently at my current company. I've never seen it done poorly. It's the standard for a reason.
        • seadan83 3y ago
• agumonkey 3y ago
  Anybody researched CMMI ?
  • cyb_ 3y ago
    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 3y ago
      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)
• perpil 3y ago
  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 https://godspeed.run
• gv83 3y ago
  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.
• svilen_dobrev 3y ago
  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.
• kramerger 3y ago
  > 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.
• oldtimerherez 3y ago
  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.
• nathants 3y ago
  a decent laboratory, health, curiosity, and joy.
• synergy20 3y ago
  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 3y ago
    Why don't you just join a startup as engineer < 5?
    • calderwoodra 3y ago
      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 3y ago
        The point is that it's hit-or-miss whether you're compensated commensurate with your impact at a C/D/E startup.
    • synergy20 3y ago
      it's a hit or miss, tried there, also tried to even run my own one, so far, so bad. but that raises an interesting question: how to find startups that have best chance to make it to join and help to make that happen?
• tekkk 3y ago
  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.
• engfan 3y ago
  GNU Hyperbole for rapid, implicit linking of all your programming artifacts and management support for handling technical complexity. One of those you can get for free.
• Incipient 3y ago
  Caffeine
• mikewarot 3y ago
  Your absolute best way to make a programmer productive is to give domain experts the tools to build an executable prototype themselves. This was the true value of Hypercard, GW Basic, Visual Basic 6, Office/VBA, Excel, Delphi, etc. They know what the actual details required for the inputs and outputs are, along with all the means to do the computations. Once they give you something that works (no matter how slow or kludgy), you have an executable specification to refactor, or rewrite, and you can A/B test to make sure your code works correctly compared to their reference/spec. You spend some valuable time on the part of the experts, but you more than make up for it in saved time doing the wrong thing across possibly years.
  • erlich 3y ago
    In my experience, the experts love to get their hands dirty and make things. Devs are gatekeeping way too much. More no-code/low-code is the way forward. It's always just a balance of how much abstraction to add.
    • majesticglue 3y ago
      for prototyping or building the actual product? No-code/low-code tools are great for prototypes, but are awful for software that is large enough. for small businesses many will not get to that point because many businesses sink by that time, but absolutely unusable for many enterprise software. Those solutions slow down devs past a certain level of complexity (and that level isn't all that high) but no-code/low-code experts will either not know any better or won't tell you. I have legitimately tried using a few, but they become a pain to work it beyond the initial prototype. I put them in the similar territory as Wordpress because they remind me of the pain of maintaining them. Non-devs always underestimate complexity of software at scale. Even devs do as well. It's not gatekeeping otherwise, devs would already be out of a job
• nickd2001 3y ago
  I dispute "slow tools" being always as much of a problem as the article claims. From personal experience, having to wait for a build to finish sometimes makes me get up, and go make a tea or empty dishwasher / hang laundry out, as result feel refreshed and/or subconscious works on a problem. So often I go back to my chair with the solution having come seemingly from nowhere. Only because of the long build time did that happen. ;). A former colleague used to find excuses to have to walk from one office building to another to pick up a cable or something, in order to let his bring solve a problem rather than sit stewing in his chair. So... productivity is complicated. ;)
  • blibble 3y ago
    never had 15 second jira/confluence page loads? my focus is lost and I start thinking about lunch
    • nickd2001 3y ago
      OK fair enough that would indeed suck ;).
• deterministic 3y ago
  Managers who have a clue and are not anti-productive. I have very rarely encountered such creatures in my 30+ years career.
• robotburrito 3y ago
  For me a lot of it is honestly just feeling like I’m appreciated.
• FlacoJones 3y ago
  Time to Release https://justkeepclicking.io/whats-your-ttr-equation/ https://justkeepclicking.io/whats-your-ttr-equation/
• stonecharioteer 3y ago
  Clear requirements. Tell me what a particular feature is supposed to do damn it. I want I code, so just let me focus on that.