13 ms·

Maximizing Developer Effectiveness

427 points by edoloughlin 6y ago

shepherdjerred 6y ago
How do you convince management to focus on improving workflows? There's often a huge focus on shipping features with that being the primary criteria for promotions.
- andrenotgiant 6y ago
  send them this article
- deleted 6y ago
  [deleted]
- jmchuster 6y ago
  There might an infinite amount of things to fix, but you have to first come up with one specific improvement to the workflow that is straightforward to implement, that can be clearly measured to improve rate of shipping features. Then convince your manager of that idea, usually by getting him/her to think that they came up with the idea on their own. Then keep on repeating this, and people will be able to accept more and more process improvements that have less and less direct ties to shipping more features, because they've seen the results of all the improvements along the way. And then eventually your manager gets promoted for doing such a great job on improving productivity in their team, and because they like and trust you, you get promoted into their vacated position.
throwarayes 6y ago
Patterns on the most effective teams I’ve worked on: - high degree of trust and emotional safety between team members. The team can safely share feedback and risk sharing our crazy ideas - high degree of care for the craft. We hold each other accountable to quality - ships, regularly, to real customers - little status seeking - goes with emotional safety - few individuals on the team need to be “in charge” or hold arbitrary titles. - the individuals are more than fairly compensated and the company shows their love for the team in big and small ways - the team talks to their customer and has a lot of empathy for their problems. They want to be accountable to them - the team has a lot of empathy for new team members and works hard to make on boarding easier - some willingness to “get in trouble” with the broader org because you know what you’re doing is right ultimately for the customer - high self starters: instead of complaining, people feel empowered to solve problems or prototype ideas without a permission structure - not too much catering to “super stars”. 1-2 heros does not a team make, the senior people make it their job to lift everyone up. The team doesn’t obsess over their high performers. There’s a lot more emphasis on emotional intelligence and empathy in an effective team than on any specific process.
- throwarayes 6y ago
  Rot sets in when: - teams no longer have a real customer, such as “big rewrites” that will ship in 3 years - teams accept low quality and slack off. One PR isn’t called out and that gives a permission structure for lower quality - a bad egg gets on the team the wrecks the feelings of emotional safety. The brilliant narcissist the company feels they need to let his/her abusiveness slide - we throw new hires “into the deep end” because they have to “take their lumps” like we did - people get territorial over code because they’re insecure and maybe not great developers. - the customer is ignored to chase the latest cool new thing - hiring standards are lowered and anybody with a pulse that walked by the tech section in the bookstore is hired - good developers stop seeing peers, and realize they do all the work, so leave for a healthier team - tech illiteracy outside the team trumps tech competency in the team. When the manager says “stop writing unit tests, just get the feature done” - any rumor “hire cheaper labor” causes your best to flee and your least qualified to jockey for status
  - gabereiser 6y ago
    What’s worse is when some of these make their way into a company that has barely gotten off the ground. Especially the narcissist.
  - droopyEyelids 6y ago
    Can you expand on "any rumor hire cheaper labor"? Im too new to understand that one.
    - jdfellow 6y ago
      Likely rumors that the company will be hiring or contracting overseas.
    - toong 6y ago
      "Now that you're all working from home anyway, I might as well outsource your job to India! That will save me a truckload of money too!"
dvt 6y ago
> There is an overwhelming amount of good advice, practices, tools, and processes that you should use to improve. I disagree. Advice is contradictory, practices and processes are often orthogonal, and tools quite literally don't exist. I say this as someone that's worked in large companies and saw how lengthy not only process feedback loops were (especially developer ↔ product team), but also engineering feedback loops (testing, deployment, dev environment setup, etc.) And I also say this as someone that works on side-projects by myself. The tooling simply isn't there. Setting up fast engineering feedback loops (multi-tiered deployment, test, dev, local, prod, etc. environments, heck even hot reloading or debugging) is needlessly difficult, or janky, or simply impossible. This goes for just about any language/framework out there: from Java, to Javascript, to Go. It's not surprising that FAANG often designs their own internal systems that handle this sort of thing (from DevOps, to automated testing, to A/B testing, to deployment). I'm a believer that this is also a space that's ripe for disruption. I want environments to just work. I want code to just compile. I want containers to just run. Without me having to start digging through documentation, looking at thirteen Stack Overflow threads, and cobbling a solution that will inevitably break 3 months from now.
- peterkos 6y ago
  > It's not surprising that FAANG often designs their own internal systems that handle this sort of thing This is one reason why I've loved using Notion. I maintain a few open source repos, and our team's process has grown organically over the past few months. Being able to use a Kanban board for one set of information, then decide that it's just better as a bulleted list; storing meeting notes from quick bullet points up to detailed step-by-step guides on how to fix some issue people had that week... The low friction to high flexibility combo is great!
- jiggawatts 6y ago
  I'm going through this right now. I'm helping a customer deploy Azure App Service (similar to AWS Elastic Beanstalk). Jesus wept. It's sooo fiddly to set up everything. The prod and non-prod environments need dozens of parameters that are all slightly different. Some of these are exposed as resource properties, making them obvious, some are environment variables that are nearly undocumented. Everything is off by default and has to be turned on. Logging. Monitoring. High availability. Secure parameter storage. Staging. On and on.... Oh, you want high availability? Sure, if you pay an extra $3K per month and switch to internal only networking, build Azure DevOps "agent" VMs in a zone-redundant set, and register a bunch of private DNS zones. Good luck automating this. There are template samples available, but they've been broken for years. Regional disaster recovery? Just duplicate everything! Okay, but not like that! Slightly differently because replication is asymmetric and you may not want active-active. Then you have to layer stuff on top to actually fail over. But not one thing at a time! That's a performance disaster. All or nothing, but that's not an Azure feature, so good luck with that... This is what I thought the public cloud provides: Some place to upload a ZIP file of code that "just runs" without me having to baby-site the infrastructure. What's actually provided is a bunch of infrastructure parts that the public cloud vendor will patch for you. Everything else is your problem.
GiorgioG 6y ago
> I often help engineering organizations that are in the midst of a transformation. This is typically both a technology transformation and a cultural transformation. For example, these organizations might be attempting to break a core monolithic system into microservices, so that they can have independent teams and adopt a DevOps approach. It's amazing this fad of microservices still hasn't subsided yet. It is the bane of every company that isn't a FAANG but has management who wants to pretend they might someday have FAANG-level scaling/development problems.
- bradlys 6y ago
  They're doing microservices because they can't make a good monolithic codebase. For some reason, CTOs are very happy to start doing microservices with high level of documentation and rigorous interfaces but completely unwilling to have a well documented and rigorously defined monolith. I don't fucking get it. It's like one layer of abstraction on top of folders. Instead of breaking up ownership by folders or whatever bullshit - they decide to breakup ownership by github repo. I'd love to be sold on it otherwise but that's what I've been told directly as the reason for the move to microservices by many companies and what I've seen at my own. Can't do a good job because your business practices suck? Fuck it - microservices, baby!
  - marshmellman 6y ago
    I think a big reason is that microservice architecture forces teams to establish clear boundaries rather than leave it to team diligence. For less centralized organizations, I think it can be a useful forcing function.
    - yeswecatan 6y ago
      Clear boundaries on multiple levels as well. I believe a _very_ big part of why people feel they need microservices is because of poor architecture and a lack of boundaries in a monolith. Every single monolith I've come across has had issues with circular dependencies and no real contracts between "apps" (as they are called in Django). I believe people see ORMs such as Django's as a way to perform one big query as opposed to many small queries. The big query spans 3 apps and 8 models. You have these things sprinkled throughout the codebase and you end up with a big ball of mud.
wbharding 6y ago
Anyone who claims to teach paths by which to optimize Developer effectiveness ought to cite data to support those claims. Until data exists to contrast the results of Company A vs Company B, we'll never be short on speculative articles.
- iainctduncan 6y ago
  Sure, but if you're a consultancy, like Thought Works, you're under watertight NDAs on everything. I work for a consultancy that helps and assesses companies too, some of them selling for north of a billion. We can share general, anonymized, observations, and I would argue some of those are very valuable simply because of the breadth of situations we get to see. But we legally can't cite specific instances. That's the biz. :-/
- onethought 6y ago
  I know, that's why Aristotle is terrible... No citation or data... are we just suppose to blindly follow the scientific method? Preposterous! Reading through Fowlers "Good Environment"/"Bad Environment" lists... I can use my own critical thinking to see why one is good, or bad. Fowler while he doesn't really get his hands dirty with these problems he is very good at rounding up the current zeitgeist and common sense in ThoughtWorks and publishing it to the world. He's rarely been flat out wrong. (I don't mean this as an appeal to authority, just how I look at this article, and Fowlers publications in general).
- ada910 6y ago
  https://www.devops-research.com/research.html https://www.devops-research.com/research.html https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations-ebook/dp/B07B9F83WM/ https://www.amazon.com/Accelerate-Software-Performing-Techno...
bradlys 6y ago
Ooph, just reading the highly effective vs low effective environment bullet points was triggering. I can think of environments I entered where a good chunk of it was highly effective and my most recent startup was plagued with the low effective one (and even then - it will still IPO). Worst part is - they really had no interest in improving it. To improve would require an entirely different management chain - one that didn't learn all their ideas in the 1990's from watching rocketships take off... I sometimes wonder who these articles are written for. Am I supposed to share this with the CTO to show them how poorly the organization is being run? No, obviously not, that'd just fast track my firing. After all - if you're in an environment of psychological safety where you can air these issues then you're probably going to not have these issues very much.
- xyzelement 6y ago
  >> I sometimes wonder who these articles are written for. If you're a Leader (big L) in an org, this gives you a way to asses your organization. If you're a leader (small l) it may give you a way to concretize your thinking around problems so you can discuss them better. >> Am I supposed to share this with the CTO to show them how poorly the organization is being run? That would be the worst way? Why don't you pick whichever problems on the list resonate the most, come up with a good case as to why it's a real impediment to your team, ideally quantify its impact, perhaps come up with some solutions, and then go have the conversation? Ultimately, it's not important whether your org looks good or bad against some checklist, the "meat" is whether you have an opportunity to be more effective against your goals. If so, people generally want to have that conversation. Especially if you go in with a realistic understanding of why things are this way and the tradeoffs. >> and even then - it will still IPO Sounds like they know what they're doing then?
  - bradlys 6y ago
    Rocketships don’t need to know what they’re doing to succeed.
    - xyzelement 6y ago
29athrowaway 6y ago
A) Short-term mindset developer: - Tech debt is for others to fix. While others cleanup after me, I will be completing my next task and paving my way to promotion. - If it works, it's good enough. It does not matter if I can't explain why it works. - Everything is an obstacle. Documentation? obstacle. Coding standards? obstacle. I just want to complete tasks. - I do exactly what I am asked for. It does not matter if it is insecure, it does not scale, or if the entire system crashes. All of that will be someone else's problem later. - Code does not have to make sense, as long as it runs it is good enough. - I worship project management. B) Sustainable mindset developer: - The cost of tech debt compounds over time. I should fix tech debt before more code depends on it and becomes more expensive to fix. - I need to understand how and why things work. Is this really working? Do I really understand what I am doing? - Reviewing relevant documentation for the technologies I use is a good idea. Making sure I understand and follow coding standards is a good idea. Well crafted coding standards can save work. - I understand that not all stakeholders are technical. I need to understand the technical implications of what I am asked to do, and push back if necessary. - Code is written once, read many times. Readability makes everyone more productive. - I acknowledge that project management documentation and tools are a form of documentation, and as such, it is not a source of truth. When it comes to things to do, the implementation is the source of truth, not tickets. Bad companies promote A), good companies promote B).
- xyzelement 6y ago
  There's also a C) Pseudo-sustainable developer, who thinks he's doing B but really over-investing in optimizing and overcomplicating (and over documenting) that which isn't critical and thus wasting a ton of time.
  - beandgaethje 6y ago
    This sounds like a junior dev on the path to B). I think the desire to do the right thing says a lot and finding that right thing takes time.
    - xyzelement 6y ago
Mc91 6y ago
> Day in the life in a low effective environment > notes that a previous feature has been approved by reviewers, she moves it into another branch that kicks off a long nightly E2E test suite that is almost always red, managed by a siloed QA team. This is not a low effective environment. A low effective environment does not have a large e2e test suite. It does not have a siloed QA team, and people write little to no unit tests, never mind integration tests. If you are in a "low effective environment", a "siloed QA team" is a godsend. At least someone is responsible solely for quality, as opposed to everyone churning out features as fast as they can. Disposing of the siloed QA team in such environments rarely helps matters.
- theptip 6y ago
  It’s all relative. Relative to the highly effective teams the article is describing, the points on the spectrum you discuss here are “low” and “lower”. Sure, low is better than lower. The article is making the case for “high” though.
jiggawatts 6y ago
Productivity and efficiency of people is one of the topics that's always fascinated me, and I've both read a lot of material on the topic and have had the opportunity to observe hundreds(!) of organisations first hand thanks to being a consultant roaming from place to place. From both scientific studies on the matter and anecdotal observation of the same, I can unequivocally state that the top three priorities are: #1) The high-level goals of the organisation must be rapidly and clearly passed down the management hierarchy so that everyone can "row in the same direction". Ambiguity about goals, or uncertainty in whether one's work is even worthwhile is an astonishingly effective destroyer of productivity. Never treat employees on a "need to know" basis, feeding them the bare minimum that you think they need. #2) There is no known method more effective at improving overall product quality than mandatory peer review of all code. Not only does this have the obvious direct benefit, but it also helps cross-train senior staff, bring junior staff up to speed, and helps improve consistency. #3) There is no known method more effective than checklists at improving the quality of manual processes. Sure, if you plan to do something a hundred times, automate it. But you know what is really easy to turn into automation? A checklist. For non-automated processes, a checklist allows junior staff to confidently produce quality. Checklists are a training aid as much as they are a tool for quality improvement. Of course, there's a very long tail of things one can do on top of those basics to improve productivity, especially of junior staff. Use an IDE. Use a code linter. Use automatic tests on checkin. Etc, etc... But none of those hold a candle to the above three in terms of raw effectiveness. To put things in perspective: I'd rather have those three things and no source control than source control and none of those three things. You can meticulously track every version of a piece of garbage and it'll still be garbage...
- xyzelement 6y ago
  I agree with #1 and #2 and will add the following: #1 - on the flip side, you need employees who give a shit about your company mission and your clients. Just like a good organization is eager to share these goals, a good employee is eager to receive them. Whenever someone doesn't care, it's a big indicator to write them off. #2 - Likewise, people have to give a shit and be critical. I used to run code reviews on my team like this - person A reviews person B's code (together, in person) and I sit behind them, not to judge B's code but to judge A's review. It's shocking to me how people want to give code "the benefit of the doubt" and don't flag things unless they are truly egregious. It doesn't help anyone when people hold back like this.
logicalmind 6y ago
I am on the precipice of starting a new project at an organization and it is a much larger and more diverse project than I have worked on before. This article provides some good food for thought, but is anyone fond of particular books or articles they've found particularly helpful? I have worked in small teams of highly-effective teams generally. But I am about to embark on a much larger team consisting of a large range of skill levels. It would be nice to lay some effective groundwork from the start that isn't overly cumbersome.
- ayewo 6y ago
  Mythical Man Month by Freddie Brooks is pretty good but is not a quick read.
lxe 6y ago
Here I am, a productive developer eager to deliver maximum value to my customers and apply my innovation to company goals. Open up JIRA and pick up a unit of work to produce today -- gotta stay faithful to those story points! Somehow, a magic team of spherical devops in a vacuum created an environment where things are just green, predictable, and are never broken. Another theoretical team of angels from a parallel universe has materialized into this one, updated all the docs, and beamed back into their universe of productivity and effectiveness. Unit of work defined, I then proceed to produce it for a few hours completely uninterrupted, since if another human being were to make contact, I'd simply explode and format my hard drive, losing all my productivity. It's break time -- I ingest 2 story points of coffee and join a game of table tennis. The ball bounces back and forth without ever touching the ground. My movements are productive, and value-adding, just like my partner's. Back to producing units of work, only half a story point left (sike! no such thing as half a story point, and no such thing as "left", as it's a measure of effort, not time. Almost got you there!). Git push! Automatic CI gains consciousness and validates that my work unit has no chance of causing a user to break our software. It gives me a thumbs up and discards its human shell to fade back into the ones and zeros. A QA engineer cries out in the distance. A metric of my productivity is logged to the OKR database. Nothing breaks, and nothing unexpected happens, as the universe is completely predictable.
- elliottkember 6y ago
  Thank you for reminding me to read more fiction.
- postit 6y ago
  Thanks. This summarizes and completes perfectly the ThoughWorker bingo. They are always dreaming about the ultimate factory line for knowledge workers, but they don’t get much done other than blog posts.
  - onethought 6y ago
    Even by the HNs/SV measure of success they just got 700 million in funding and a 4.6 billion valuation... Just from writing blog posts apparently.
logifail 6y ago
Q: Does anyone else find the body text hard to read? Small and light grey text on a white background really doesn't work for my aging Mk I eyeballs.
choeger 6y ago
Did anyone else notice that there is no software engineering management involved in the "ideal" picture? In this ideology, every developer acts autonomously, even by deploying to production. This removed all technical responsibilities from the well-payed management people. Conflicts? Resource management? Scheduling? Happens to other people. At the core of this ideology lies the principle that every software is just a bag of fully orthogonal features that can be implemented completely independent of each other and will play nicely together. If this assumption does not hold, it's the developer's fault (aka "ownership"). Dear developer colleagues, do not fall for this trap. Hold your managers responsible. Let them make the difficult decisions. Real leadership should lift some burden from the people being lead.
- UK-Al05 6y ago
  I'm presuming in this ideal land, the stories are already ordered in the most optimal way. So no scheduling conflict. Resource and release conflicts don't appear if you have the right infrastructure.
  - choeger 6y ago
    Are you serious? The "right" infrastructure? Are you limiting your view to a single service, running on a big cluster? Because even then there are permanent conflicts in the persistence layer and resource conflicts express themselves in huge infrastructure bills. But things get really messy when your software is distributed in heterogeneous environments. Say you ship a database yourselves. Or a multi-platform app, or a game, or the control software for medical devices, or... Software development is not just running the next SaaS product.
    - UK-Al05 6y ago
      Give me some concrete examples. Higher infrastructure bills for spinning up new hardware is often cheaper than fixing resource conflicts
- deleted 6y ago
  [deleted]
leghifla 6y ago
I am the first to ask for quick feedback loops, which makes the dev environment so much enjoyable. But I have also seen some detrimental long term effect of this. I have seen developpers "coding to the test". By that I mean they are modifying a piece of code they do not know well, and assume that if test pass, that must be good. Without understanding that test will never cover all possible inputs/states of the system. This "coding to the test" can appear very fast with a quick feedback loop, making possible to "monkey code" something until it passes. If you do not have careful review, by people knowing the system, this will end badly, with race conditions only appearing in production, integration failing randomly.
kohlerm 6y ago
IMHO the article has some good points. E.g. I would guess a lot of organizations use ancient build tools ( maven always doing a full rebuild) and try to mitigate slow build times by going to towards small Microservices.
knuthsat 6y ago
Tools and stuff around the code will still not allow an effective environment. Code design is a huge bottle-neck. I've been a part of 10+ engineering teams that have all the right tools and stuff, everything around the code is really frictionless and runs well (CI, tests etc.). But the code is so badly written and designed that adding new features needs edits of dozens of files and sometimes even copy-pasting files (because of circular dependencies and singletons everywhere). I guess existing developers can be effective in this kind of environment but getting new ones to contribute will still be a chore. Although, even existing ones, when they forget what they did, start getting difficulties creating new functionality. For example, the biggest issue I've seen is "dependency injection" mindset. It's a mindset that dependency injection library solves the dependency issue and you can just inject anything you need anywhere. The entangled mess that this creates is horrible. Yeah, all of the objects initialize correctly but not thinking about separation of concern, proper encapsulation or what really needs the whole dependency will create a mess.
deleted 6y ago
[deleted]
bullen 6y ago
This has been my primary focus for two decades, I litteraly can't work in slow environements: 1) I encourage people to use JavaSE on the server and hot-deploy to the servers directly with async. non-blocking: http://github.com/tinspin/rupy http://github.com/tinspin/rupy 2) For clientside: mostly C syntax (compiled with C++ compiler) is your best option and I recently made a in-app debugger for Windows: http://move.rupy.se/file/stack.html http://move.rupy.se/file/stack.html (this delivers something much worse than a Java stacktrace but as good as it gets without a VM). I also hot-deploy the C/C++ app code with a .dll to my .exe and the debugger works for that hot-deployed .dll too! On linux the .so hot-deploy works as well, the only reason I have not taken the addr2line source to port the in-app debugger is that I know which hardware I'm working on as I only plan to ship linux on ARM! Fight features where you can, in this case limit your porting and exposure to unknown unknowns! Potentially I can hot-deploy the client .dll/.so over my hot-deployed server pipeline, making the platform a distributed real-time system where you can patch the native code in real-time remotely while users are using your app! Mostly usable for development I guess (¯\_(ツ)_/¯), but still really exiting!
bob33212 6y ago
I call this "silver bullet consulting". The reality is that their customers have slapped a developer title on anyone willing to take their 80k/year job. And then they hire "product managers" who fill out schedules with arbitrary dates. Then when "dates are missed" meeting are added and developer training is added. That makes productivity go down even more. In come the consultants who will fix everything with a change to processes instead of being honest and saying that they need to fire everyone and start over from scratch.
g051051 6y ago
> Very sensibly, most companies are on a journey towards achieving this environment Yes, until they realize how much of a crock it all is, and go back to actually getting work done. Backstage looks interesting though, so maybe I'll get something good out of the article.
lrossi 6y ago
So CI, automated tests, SCM, small patches, API docs, stand ups and the ability to take breaks. This is not a “highly effective environment”, it’s the bare minimum to have a functional environment. Might have been good advice in the late 90s though.
nickjj 6y ago
I don't think I agree with his feedback loop chart. He claims 5-15 seconds to validate that a local code change works is highly effective. But in practice, that amount of time makes for one of the most unfriendly environments to be in. For example having to wait 5-7 seconds for an AWS SAM (Serverless) Lambda function to be built and locally invoked is so much worse than making a code change in a Flask, Rails, Django, Laravel, Node, Phoenix, etc. app and seeing the change as fast as it takes you to focus your browser and reload, or running something in a REPL. When you do such a thing 100 times in a few hours those 5+ second pauses are deadly for motivation and productivity. It's a constant reminder at how crappy the development experience is and it's also not long enough to do something else while it completes so you're stuck wasting your life away on a tool. Is anyone really happy when they need to wait 10 seconds to see a change when developing a web app? I think the web context is important because you can relate to it from past experiences. In 2001 there was a near instant feedback loop with making a change to a PHP page and reloading the browser. Anything less than that 20 years later seems like a direct downgrade, especially considering computers are probably 1,000x faster today.
0xbadcafebee 6y ago
What I love about shit like this is they're walking around going "If you do X your productivity will increase." Assuming this is true, you're still fucked, because nobody can force your executives to then force their employees to do X. If the executive doesn't tell people to do it, nobody will. So knowing what makes for good productivity is still worthless unless a handful of chuckleheads at the top actually make it happen. And they won't, for the same reason nobody below them is doing it.
alisausaaaaaa 6y ago
Wanna have hot-lovin' conversations? You’re on the right way! - https://adultlove.life https://adultlove.life

427 points by edoloughlin 6y ago

How do you convince management to focus on improving workflows? There's often a huge focus on shipping features with that being the primary criteria for promotions.

andrenotgiant 6y ago
send them this article
deleted 6y ago
[deleted]
jmchuster 6y ago
There might an infinite amount of things to fix, but you have to first come up with one specific improvement to the workflow that is straightforward to implement, that can be clearly measured to improve rate of shipping features. Then convince your manager of that idea, usually by getting him/her to think that they came up with the idea on their own. Then keep on repeating this, and people will be able to accept more and more process improvements that have less and less direct ties to shipping more features, because they've seen the results of all the improvements along the way. And then eventually your manager gets promoted for doing such a great job on improving productivity in their team, and because they like and trust you, you get promoted into their vacated position.

throwarayes 6y ago

Patterns on the most effective teams I’ve worked on: - high degree of trust and emotional safety between team members. The team can safely share feedback and risk sharing our crazy ideas - high degree of care for the craft. We hold each other accountable to quality - ships, regularly, to real customers - little status seeking - goes with emotional safety - few individuals on the team need to be “in charge” or hold arbitrary titles. - the individuals are more than fairly compensated and the company shows their love for the team in big and small ways - the team talks to their customer and has a lot of empathy for their problems. They want to be accountable to them - the team has a lot of empathy for new team members and works hard to make on boarding easier - some willingness to “get in trouble” with the broader org because you know what you’re doing is right ultimately for the customer - high self starters: instead of complaining, people feel empowered to solve problems or prototype ideas without a permission structure - not too much catering to “super stars”. 1-2 heros does not a team make, the senior people make it their job to lift everyone up. The team doesn’t obsess over their high performers. There’s a lot more emphasis on emotional intelligence and empathy in an effective team than on any specific process.

throwarayes 6y ago
Rot sets in when: - teams no longer have a real customer, such as “big rewrites” that will ship in 3 years - teams accept low quality and slack off. One PR isn’t called out and that gives a permission structure for lower quality - a bad egg gets on the team the wrecks the feelings of emotional safety. The brilliant narcissist the company feels they need to let his/her abusiveness slide - we throw new hires “into the deep end” because they have to “take their lumps” like we did - people get territorial over code because they’re insecure and maybe not great developers. - the customer is ignored to chase the latest cool new thing - hiring standards are lowered and anybody with a pulse that walked by the tech section in the bookstore is hired - good developers stop seeing peers, and realize they do all the work, so leave for a healthier team - tech illiteracy outside the team trumps tech competency in the team. When the manager says “stop writing unit tests, just get the feature done” - any rumor “hire cheaper labor” causes your best to flee and your least qualified to jockey for status
- gabereiser 6y ago
  What’s worse is when some of these make their way into a company that has barely gotten off the ground. Especially the narcissist.
- droopyEyelids 6y ago
  Can you expand on "any rumor hire cheaper labor"? Im too new to understand that one.
  - jdfellow 6y ago
    Likely rumors that the company will be hiring or contracting overseas.
  - toong 6y ago
    "Now that you're all working from home anyway, I might as well outsource your job to India! That will save me a truckload of money too!"

dvt 6y ago

> There is an overwhelming amount of good advice, practices, tools, and processes that you should use to improve. I disagree. Advice is contradictory, practices and processes are often orthogonal, and tools quite literally don't exist. I say this as someone that's worked in large companies and saw how lengthy not only process feedback loops were (especially developer ↔ product team), but also engineering feedback loops (testing, deployment, dev environment setup, etc.) And I also say this as someone that works on side-projects by myself. The tooling simply isn't there. Setting up fast engineering feedback loops (multi-tiered deployment, test, dev, local, prod, etc. environments, heck even hot reloading or debugging) is needlessly difficult, or janky, or simply impossible. This goes for just about any language/framework out there: from Java, to Javascript, to Go. It's not surprising that FAANG often designs their own internal systems that handle this sort of thing (from DevOps, to automated testing, to A/B testing, to deployment). I'm a believer that this is also a space that's ripe for disruption. I want environments to just work. I want code to just compile. I want containers to just run. Without me having to start digging through documentation, looking at thirteen Stack Overflow threads, and cobbling a solution that will inevitably break 3 months from now.

peterkos 6y ago
> It's not surprising that FAANG often designs their own internal systems that handle this sort of thing This is one reason why I've loved using Notion. I maintain a few open source repos, and our team's process has grown organically over the past few months. Being able to use a Kanban board for one set of information, then decide that it's just better as a bulleted list; storing meeting notes from quick bullet points up to detailed step-by-step guides on how to fix some issue people had that week... The low friction to high flexibility combo is great!
jiggawatts 6y ago
I'm going through this right now. I'm helping a customer deploy Azure App Service (similar to AWS Elastic Beanstalk). Jesus wept. It's sooo fiddly to set up everything. The prod and non-prod environments need dozens of parameters that are all slightly different. Some of these are exposed as resource properties, making them obvious, some are environment variables that are nearly undocumented. Everything is off by default and has to be turned on. Logging. Monitoring. High availability. Secure parameter storage. Staging. On and on.... Oh, you want high availability? Sure, if you pay an extra $3K per month and switch to internal only networking, build Azure DevOps "agent" VMs in a zone-redundant set, and register a bunch of private DNS zones. Good luck automating this. There are template samples available, but they've been broken for years. Regional disaster recovery? Just duplicate everything! Okay, but not like that! Slightly differently because replication is asymmetric and you may not want active-active. Then you have to layer stuff on top to actually fail over. But not one thing at a time! That's a performance disaster. All or nothing, but that's not an Azure feature, so good luck with that... This is what I thought the public cloud provides: Some place to upload a ZIP file of code that "just runs" without me having to baby-site the infrastructure. What's actually provided is a bunch of infrastructure parts that the public cloud vendor will patch for you. Everything else is your problem.

GiorgioG 6y ago

> I often help engineering organizations that are in the midst of a transformation. This is typically both a technology transformation and a cultural transformation. For example, these organizations might be attempting to break a core monolithic system into microservices, so that they can have independent teams and adopt a DevOps approach. It's amazing this fad of microservices still hasn't subsided yet. It is the bane of every company that isn't a FAANG but has management who wants to pretend they might someday have FAANG-level scaling/development problems.

bradlys 6y ago
They're doing microservices because they can't make a good monolithic codebase. For some reason, CTOs are very happy to start doing microservices with high level of documentation and rigorous interfaces but completely unwilling to have a well documented and rigorously defined monolith. I don't fucking get it. It's like one layer of abstraction on top of folders. Instead of breaking up ownership by folders or whatever bullshit - they decide to breakup ownership by github repo. I'd love to be sold on it otherwise but that's what I've been told directly as the reason for the move to microservices by many companies and what I've seen at my own. Can't do a good job because your business practices suck? Fuck it - microservices, baby!
- marshmellman 6y ago
  I think a big reason is that microservice architecture forces teams to establish clear boundaries rather than leave it to team diligence. For less centralized organizations, I think it can be a useful forcing function.
  - yeswecatan 6y ago
    Clear boundaries on multiple levels as well. I believe a _very_ big part of why people feel they need microservices is because of poor architecture and a lack of boundaries in a monolith. Every single monolith I've come across has had issues with circular dependencies and no real contracts between "apps" (as they are called in Django). I believe people see ORMs such as Django's as a way to perform one big query as opposed to many small queries. The big query spans 3 apps and 8 models. You have these things sprinkled throughout the codebase and you end up with a big ball of mud.

wbharding 6y ago

Anyone who claims to teach paths by which to optimize Developer effectiveness ought to cite data to support those claims. Until data exists to contrast the results of Company A vs Company B, we'll never be short on speculative articles.

iainctduncan 6y ago
Sure, but if you're a consultancy, like Thought Works, you're under watertight NDAs on everything. I work for a consultancy that helps and assesses companies too, some of them selling for north of a billion. We can share general, anonymized, observations, and I would argue some of those are very valuable simply because of the breadth of situations we get to see. But we legally can't cite specific instances. That's the biz. :-/
onethought 6y ago
I know, that's why Aristotle is terrible... No citation or data... are we just suppose to blindly follow the scientific method? Preposterous! Reading through Fowlers "Good Environment"/"Bad Environment" lists... I can use my own critical thinking to see why one is good, or bad. Fowler while he doesn't really get his hands dirty with these problems he is very good at rounding up the current zeitgeist and common sense in ThoughtWorks and publishing it to the world. He's rarely been flat out wrong. (I don't mean this as an appeal to authority, just how I look at this article, and Fowlers publications in general).
ada910 6y ago
https://www.devops-research.com/research.html https://www.devops-research.com/research.html https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations-ebook/dp/B07B9F83WM/ https://www.amazon.com/Accelerate-Software-Performing-Techno...

bradlys 6y ago

Ooph, just reading the highly effective vs low effective environment bullet points was triggering. I can think of environments I entered where a good chunk of it was highly effective and my most recent startup was plagued with the low effective one (and even then - it will still IPO). Worst part is - they really had no interest in improving it. To improve would require an entirely different management chain - one that didn't learn all their ideas in the 1990's from watching rocketships take off... I sometimes wonder who these articles are written for. Am I supposed to share this with the CTO to show them how poorly the organization is being run? No, obviously not, that'd just fast track my firing. After all - if you're in an environment of psychological safety where you can air these issues then you're probably going to not have these issues very much.

xyzelement 6y ago
>> I sometimes wonder who these articles are written for. If you're a Leader (big L) in an org, this gives you a way to asses your organization. If you're a leader (small l) it may give you a way to concretize your thinking around problems so you can discuss them better. >> Am I supposed to share this with the CTO to show them how poorly the organization is being run? That would be the worst way? Why don't you pick whichever problems on the list resonate the most, come up with a good case as to why it's a real impediment to your team, ideally quantify its impact, perhaps come up with some solutions, and then go have the conversation? Ultimately, it's not important whether your org looks good or bad against some checklist, the "meat" is whether you have an opportunity to be more effective against your goals. If so, people generally want to have that conversation. Especially if you go in with a realistic understanding of why things are this way and the tradeoffs. >> and even then - it will still IPO Sounds like they know what they're doing then?
- bradlys 6y ago
  Rocketships don’t need to know what they’re doing to succeed.
  - xyzelement 6y ago

29athrowaway 6y ago

A) Short-term mindset developer: - Tech debt is for others to fix. While others cleanup after me, I will be completing my next task and paving my way to promotion. - If it works, it's good enough. It does not matter if I can't explain why it works. - Everything is an obstacle. Documentation? obstacle. Coding standards? obstacle. I just want to complete tasks. - I do exactly what I am asked for. It does not matter if it is insecure, it does not scale, or if the entire system crashes. All of that will be someone else's problem later. - Code does not have to make sense, as long as it runs it is good enough. - I worship project management. B) Sustainable mindset developer: - The cost of tech debt compounds over time. I should fix tech debt before more code depends on it and becomes more expensive to fix. - I need to understand how and why things work. Is this really working? Do I really understand what I am doing? - Reviewing relevant documentation for the technologies I use is a good idea. Making sure I understand and follow coding standards is a good idea. Well crafted coding standards can save work. - I understand that not all stakeholders are technical. I need to understand the technical implications of what I am asked to do, and push back if necessary. - Code is written once, read many times. Readability makes everyone more productive. - I acknowledge that project management documentation and tools are a form of documentation, and as such, it is not a source of truth. When it comes to things to do, the implementation is the source of truth, not tickets. Bad companies promote A), good companies promote B).

xyzelement 6y ago
There's also a C) Pseudo-sustainable developer, who thinks he's doing B but really over-investing in optimizing and overcomplicating (and over documenting) that which isn't critical and thus wasting a ton of time.
- beandgaethje 6y ago
  This sounds like a junior dev on the path to B). I think the desire to do the right thing says a lot and finding that right thing takes time.
  - xyzelement 6y ago

Mc91 6y ago

> Day in the life in a low effective environment > notes that a previous feature has been approved by reviewers, she moves it into another branch that kicks off a long nightly E2E test suite that is almost always red, managed by a siloed QA team. This is not a low effective environment. A low effective environment does not have a large e2e test suite. It does not have a siloed QA team, and people write little to no unit tests, never mind integration tests. If you are in a "low effective environment", a "siloed QA team" is a godsend. At least someone is responsible solely for quality, as opposed to everyone churning out features as fast as they can. Disposing of the siloed QA team in such environments rarely helps matters.

theptip 6y ago
It’s all relative. Relative to the highly effective teams the article is describing, the points on the spectrum you discuss here are “low” and “lower”. Sure, low is better than lower. The article is making the case for “high” though.

jiggawatts 6y ago

Productivity and efficiency of people is one of the topics that's always fascinated me, and I've both read a lot of material on the topic and have had the opportunity to observe hundreds(!) of organisations first hand thanks to being a consultant roaming from place to place. From both scientific studies on the matter and anecdotal observation of the same, I can unequivocally state that the top three priorities are: #1) The high-level goals of the organisation must be rapidly and clearly passed down the management hierarchy so that everyone can "row in the same direction". Ambiguity about goals, or uncertainty in whether one's work is even worthwhile is an astonishingly effective destroyer of productivity. Never treat employees on a "need to know" basis, feeding them the bare minimum that you think they need. #2) There is no known method more effective at improving overall product quality than mandatory peer review of all code. Not only does this have the obvious direct benefit, but it also helps cross-train senior staff, bring junior staff up to speed, and helps improve consistency. #3) There is no known method more effective than checklists at improving the quality of manual processes. Sure, if you plan to do something a hundred times, automate it. But you know what is really easy to turn into automation? A checklist. For non-automated processes, a checklist allows junior staff to confidently produce quality. Checklists are a training aid as much as they are a tool for quality improvement. Of course, there's a very long tail of things one can do on top of those basics to improve productivity, especially of junior staff. Use an IDE. Use a code linter. Use automatic tests on checkin. Etc, etc... But none of those hold a candle to the above three in terms of raw effectiveness. To put things in perspective: I'd rather have those three things and no source control than source control and none of those three things. You can meticulously track every version of a piece of garbage and it'll still be garbage...

xyzelement 6y ago
I agree with #1 and #2 and will add the following: #1 - on the flip side, you need employees who give a shit about your company mission and your clients. Just like a good organization is eager to share these goals, a good employee is eager to receive them. Whenever someone doesn't care, it's a big indicator to write them off. #2 - Likewise, people have to give a shit and be critical. I used to run code reviews on my team like this - person A reviews person B's code (together, in person) and I sit behind them, not to judge B's code but to judge A's review. It's shocking to me how people want to give code "the benefit of the doubt" and don't flag things unless they are truly egregious. It doesn't help anyone when people hold back like this.

logicalmind 6y ago

I am on the precipice of starting a new project at an organization and it is a much larger and more diverse project than I have worked on before. This article provides some good food for thought, but is anyone fond of particular books or articles they've found particularly helpful? I have worked in small teams of highly-effective teams generally. But I am about to embark on a much larger team consisting of a large range of skill levels. It would be nice to lay some effective groundwork from the start that isn't overly cumbersome.

ayewo 6y ago
Mythical Man Month by Freddie Brooks is pretty good but is not a quick read.

lxe 6y ago

Here I am, a productive developer eager to deliver maximum value to my customers and apply my innovation to company goals. Open up JIRA and pick up a unit of work to produce today -- gotta stay faithful to those story points! Somehow, a magic team of spherical devops in a vacuum created an environment where things are just green, predictable, and are never broken. Another theoretical team of angels from a parallel universe has materialized into this one, updated all the docs, and beamed back into their universe of productivity and effectiveness. Unit of work defined, I then proceed to produce it for a few hours completely uninterrupted, since if another human being were to make contact, I'd simply explode and format my hard drive, losing all my productivity. It's break time -- I ingest 2 story points of coffee and join a game of table tennis. The ball bounces back and forth without ever touching the ground. My movements are productive, and value-adding, just like my partner's. Back to producing units of work, only half a story point left (sike! no such thing as half a story point, and no such thing as "left", as it's a measure of effort, not time. Almost got you there!). Git push! Automatic CI gains consciousness and validates that my work unit has no chance of causing a user to break our software. It gives me a thumbs up and discards its human shell to fade back into the ones and zeros. A QA engineer cries out in the distance. A metric of my productivity is logged to the OKR database. Nothing breaks, and nothing unexpected happens, as the universe is completely predictable.

elliottkember 6y ago
Thank you for reminding me to read more fiction.
postit 6y ago
Thanks. This summarizes and completes perfectly the ThoughWorker bingo. They are always dreaming about the ultimate factory line for knowledge workers, but they don’t get much done other than blog posts.
- onethought 6y ago
  Even by the HNs/SV measure of success they just got 700 million in funding and a 4.6 billion valuation... Just from writing blog posts apparently.

logifail 6y ago

Q: Does anyone else find the body text hard to read? Small and light grey text on a white background really doesn't work for my aging Mk I eyeballs.

choeger 6y ago

Did anyone else notice that there is no software engineering management involved in the "ideal" picture? In this ideology, every developer acts autonomously, even by deploying to production. This removed all technical responsibilities from the well-payed management people. Conflicts? Resource management? Scheduling? Happens to other people. At the core of this ideology lies the principle that every software is just a bag of fully orthogonal features that can be implemented completely independent of each other and will play nicely together. If this assumption does not hold, it's the developer's fault (aka "ownership"). Dear developer colleagues, do not fall for this trap. Hold your managers responsible. Let them make the difficult decisions. Real leadership should lift some burden from the people being lead.

UK-Al05 6y ago
I'm presuming in this ideal land, the stories are already ordered in the most optimal way. So no scheduling conflict. Resource and release conflicts don't appear if you have the right infrastructure.
- choeger 6y ago
  Are you serious? The "right" infrastructure? Are you limiting your view to a single service, running on a big cluster? Because even then there are permanent conflicts in the persistence layer and resource conflicts express themselves in huge infrastructure bills. But things get really messy when your software is distributed in heterogeneous environments. Say you ship a database yourselves. Or a multi-platform app, or a game, or the control software for medical devices, or... Software development is not just running the next SaaS product.
  - UK-Al05 6y ago
    Give me some concrete examples. Higher infrastructure bills for spinning up new hardware is often cheaper than fixing resource conflicts
deleted 6y ago
[deleted]

leghifla 6y ago

I am the first to ask for quick feedback loops, which makes the dev environment so much enjoyable. But I have also seen some detrimental long term effect of this. I have seen developpers "coding to the test". By that I mean they are modifying a piece of code they do not know well, and assume that if test pass, that must be good. Without understanding that test will never cover all possible inputs/states of the system. This "coding to the test" can appear very fast with a quick feedback loop, making possible to "monkey code" something until it passes. If you do not have careful review, by people knowing the system, this will end badly, with race conditions only appearing in production, integration failing randomly.

kohlerm 6y ago

IMHO the article has some good points. E.g. I would guess a lot of organizations use ancient build tools ( maven always doing a full rebuild) and try to mitigate slow build times by going to towards small Microservices.

knuthsat 6y ago

Tools and stuff around the code will still not allow an effective environment. Code design is a huge bottle-neck. I've been a part of 10+ engineering teams that have all the right tools and stuff, everything around the code is really frictionless and runs well (CI, tests etc.). But the code is so badly written and designed that adding new features needs edits of dozens of files and sometimes even copy-pasting files (because of circular dependencies and singletons everywhere). I guess existing developers can be effective in this kind of environment but getting new ones to contribute will still be a chore. Although, even existing ones, when they forget what they did, start getting difficulties creating new functionality. For example, the biggest issue I've seen is "dependency injection" mindset. It's a mindset that dependency injection library solves the dependency issue and you can just inject anything you need anywhere. The entangled mess that this creates is horrible. Yeah, all of the objects initialize correctly but not thinking about separation of concern, proper encapsulation or what really needs the whole dependency will create a mess.

deleted 6y ago

[deleted]

bullen 6y ago

This has been my primary focus for two decades, I litteraly can't work in slow environements: 1) I encourage people to use JavaSE on the server and hot-deploy to the servers directly with async. non-blocking: http://github.com/tinspin/rupy http://github.com/tinspin/rupy 2) For clientside: mostly C syntax (compiled with C++ compiler) is your best option and I recently made a in-app debugger for Windows: http://move.rupy.se/file/stack.html http://move.rupy.se/file/stack.html (this delivers something much worse than a Java stacktrace but as good as it gets without a VM). I also hot-deploy the C/C++ app code with a .dll to my .exe and the debugger works for that hot-deployed .dll too! On linux the .so hot-deploy works as well, the only reason I have not taken the addr2line source to port the in-app debugger is that I know which hardware I'm working on as I only plan to ship linux on ARM! Fight features where you can, in this case limit your porting and exposure to unknown unknowns! Potentially I can hot-deploy the client .dll/.so over my hot-deployed server pipeline, making the platform a distributed real-time system where you can patch the native code in real-time remotely while users are using your app! Mostly usable for development I guess (¯\_(ツ)_/¯), but still really exiting!

bob33212 6y ago

I call this "silver bullet consulting". The reality is that their customers have slapped a developer title on anyone willing to take their 80k/year job. And then they hire "product managers" who fill out schedules with arbitrary dates. Then when "dates are missed" meeting are added and developer training is added. That makes productivity go down even more. In come the consultants who will fix everything with a change to processes instead of being honest and saying that they need to fire everyone and start over from scratch.

g051051 6y ago

> Very sensibly, most companies are on a journey towards achieving this environment Yes, until they realize how much of a crock it all is, and go back to actually getting work done. Backstage looks interesting though, so maybe I'll get something good out of the article.

lrossi 6y ago

So CI, automated tests, SCM, small patches, API docs, stand ups and the ability to take breaks. This is not a “highly effective environment”, it’s the bare minimum to have a functional environment. Might have been good advice in the late 90s though.

nickjj 6y ago

I don't think I agree with his feedback loop chart. He claims 5-15 seconds to validate that a local code change works is highly effective. But in practice, that amount of time makes for one of the most unfriendly environments to be in. For example having to wait 5-7 seconds for an AWS SAM (Serverless) Lambda function to be built and locally invoked is so much worse than making a code change in a Flask, Rails, Django, Laravel, Node, Phoenix, etc. app and seeing the change as fast as it takes you to focus your browser and reload, or running something in a REPL. When you do such a thing 100 times in a few hours those 5+ second pauses are deadly for motivation and productivity. It's a constant reminder at how crappy the development experience is and it's also not long enough to do something else while it completes so you're stuck wasting your life away on a tool. Is anyone really happy when they need to wait 10 seconds to see a change when developing a web app? I think the web context is important because you can relate to it from past experiences. In 2001 there was a near instant feedback loop with making a change to a PHP page and reloading the browser. Anything less than that 20 years later seems like a direct downgrade, especially considering computers are probably 1,000x faster today.

0xbadcafebee 6y ago

What I love about shit like this is they're walking around going "If you do X your productivity will increase." Assuming this is true, you're still fucked, because nobody can force your executives to then force their employees to do X. If the executive doesn't tell people to do it, nobody will. So knowing what makes for good productivity is still worthless unless a handful of chuckleheads at the top actually make it happen. And they won't, for the same reason nobody below them is doing it.

alisausaaaaaa 6y ago

Wanna have hot-lovin' conversations? You’re on the right way! - https://adultlove.life https://adultlove.life