TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Maximizing Developer Effectiveness

427 pointsby edoloughlinover 4 years ago

22 comments

lxeover 4 years ago
Here I am, a productive developer eager to deliver maximum value to my customers and apply my innovation to company goals.<p>Open up JIRA and pick up a unit of work to produce today -- gotta stay faithful to those story points!<p>Somehow, a magic team of spherical devops in a vacuum created an environment where things are just green, predictable, and are never broken.<p>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.<p>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&#x27;d simply explode and format my hard drive, losing all my productivity.<p>It&#x27;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&#x27;s.<p>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 &quot;left&quot;, as it&#x27;s a measure of effort, not time. Almost got you there!).<p>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.<p>A metric of my productivity is logged to the OKR database.<p>Nothing breaks, and nothing unexpected happens, as the universe is completely predictable.
评论 #25801134 未加载
评论 #25800913 未加载
评论 #25801130 未加载
评论 #25801266 未加载
评论 #25801210 未加载
评论 #25802107 未加载
评论 #25800965 未加载
评论 #25800840 未加载
评论 #25800953 未加载
评论 #25801795 未加载
评论 #25805421 未加载
评论 #25805407 未加载
评论 #25801916 未加载
评论 #25804148 未加载
评论 #25801933 未加载
throwarayesover 4 years ago
Patterns on the most effective teams I’ve worked on:<p>- high degree of trust and emotional safety between team members. The team can safely share feedback and risk sharing our crazy ideas<p>- high degree of care for the craft. We hold each other accountable to quality<p>- ships, regularly, to real customers<p>- little status seeking - goes with emotional safety - few individuals on the team need to be “in charge” or hold arbitrary titles.<p>- the individuals are more than fairly compensated and the company shows their love for the team in big and small ways<p>- the team talks to their customer and has a lot of empathy for their problems. They want to be accountable to them<p>- the team has a lot of empathy for new team members and works hard to make on boarding easier<p>- some willingness to “get in trouble” with the broader org because you know what you’re doing is right ultimately for the customer<p>- high self starters: instead of complaining, people feel empowered to solve problems or prototype ideas without a permission structure<p>- 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.<p>There’s a lot more emphasis on emotional intelligence and empathy in an effective team than on any specific process.
评论 #25800163 未加载
评论 #25943410 未加载
评论 #25801557 未加载
评论 #25816151 未加载
dvtover 4 years ago
&gt; There is an overwhelming amount of good advice, practices, tools, and processes that you should use to improve.<p>I disagree. Advice is contradictory, practices and processes are often orthogonal, and tools quite literally don&#x27;t exist. I say this as someone that&#x27;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.)<p>And I also say this as someone that works on side-projects by myself. The tooling simply isn&#x27;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&#x2F;framework out there: from Java, to Javascript, to Go.<p>It&#x27;s not surprising that FAANG often designs their own internal systems that handle this sort of thing (from DevOps, to automated testing, to A&#x2F;B testing, to deployment). I&#x27;m a believer that this is also a space that&#x27;s ripe for disruption. I want environments to just <i>work</i>. I want code to just <i>compile</i>. I want containers to just <i>run</i>. 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.
评论 #25800613 未加载
评论 #25800875 未加载
评论 #25802230 未加载
评论 #25801033 未加载
评论 #25800418 未加载
评论 #25800646 未加载
评论 #25800755 未加载
评论 #25810628 未加载
评论 #25800943 未加载
评论 #25811236 未加载
jiggawattsover 4 years ago
Productivity and efficiency of people is one of the topics that&#x27;s always fascinated me, and I&#x27;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.<p>From both scientific studies on the matter and anecdotal observation of the same, I can unequivocally state that the top three priorities are:<p>#1) The high-level goals of the organisation must be rapidly and clearly passed down the management hierarchy so that everyone can &quot;row in the same direction&quot;. Ambiguity about goals, or uncertainty in whether one&#x27;s work is even worthwhile is an astonishingly effective destroyer of productivity. Never treat employees on a &quot;need to know&quot; basis, feeding them the bare minimum that you think they need.<p>#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.<p>#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.<p>Of course, there&#x27;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.<p>To put things in perspective: I&#x27;d rather have those three things and <i>no source control</i> than source control and none of those three things. You can meticulously track every version of a piece of garbage and it&#x27;ll still be garbage...
评论 #25800604 未加载
评论 #25800678 未加载
评论 #25800856 未加载
GiorgioGover 4 years ago
&gt; 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.<p>It&#x27;s amazing this fad of microservices still hasn&#x27;t subsided yet. It is the bane of every company that isn&#x27;t a FAANG but has management who wants to pretend they might someday have FAANG-level scaling&#x2F;development problems.
评论 #25800426 未加载
评论 #25801051 未加载
评论 #25800503 未加载
评论 #25801717 未加载
评论 #25801561 未加载
29athrowawayover 4 years ago
A) Short-term mindset developer:<p>- 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.<p>- If it works, it&#x27;s good enough. It does not matter if I can&#x27;t explain why it works.<p>- Everything is an obstacle. Documentation? obstacle. Coding standards? obstacle. I just want to complete tasks.<p>- 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&#x27;s problem later.<p>- Code does not have to make sense, as long as it runs it is good enough.<p>- I worship project management.<p>B) Sustainable mindset developer:<p>- 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.<p>- I need to understand how and why things work. Is this really working? Do I really understand what I am doing?<p>- 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.<p>- 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.<p>- Code is written once, read many times. Readability makes everyone more productive.<p>- 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.<p>Bad companies promote A), good companies promote B).
评论 #25800526 未加载
choegerover 4 years ago
Did anyone else notice that there is no software engineering management involved in the &quot;ideal&quot; 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&#x27;s the developer&#x27;s fault (aka &quot;ownership&quot;).<p>Dear developer colleagues, do not fall for this trap. Hold your managers responsible. Let <i>them</i> make the difficult decisions. Real leadership should lift some burden from the people being lead.
评论 #25801425 未加载
评论 #25804350 未加载
bradlysover 4 years 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&#x27;t learn all their ideas in the 1990&#x27;s from watching rocketships take off...<p>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&#x27;d just fast track my firing. After all - if you&#x27;re in an environment of psychological safety where you can air these issues then you&#x27;re probably going to not have these issues very much.
评论 #25800550 未加载
nickjjover 4 years ago
I don&#x27;t think I agree with his feedback loop chart.<p>He claims 5-15 seconds to validate that a local code change works is highly effective.<p>But in practice, that amount of time makes for one of the most unfriendly environments to be in.<p>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.<p>When you do such a thing 100 times in a few hours those 5+ second pauses are deadly for motivation and productivity. It&#x27;s a constant reminder at how crappy the development experience is and it&#x27;s also not long enough to do something else while it completes so you&#x27;re stuck wasting your life away on a tool.<p>Is anyone really happy when they need to wait 10 seconds to see a change when developing a web app?<p>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.
Mc91over 4 years ago
&gt; Day in the life in a low effective environment<p>&gt; 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.<p>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.<p>If you are in a &quot;low effective environment&quot;, a &quot;siloed QA team&quot; 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.
评论 #25800589 未加载
wbhardingover 4 years 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&#x27;ll never be short on speculative articles.
评论 #25801034 未加载
评论 #25800490 未加载
评论 #25806295 未加载
bullenover 4 years ago
This has been my primary focus for two decades, I litteraly can&#x27;t work in slow environements:<p>1) I encourage people to use JavaSE on the server and hot-deploy to the servers directly with async. non-blocking: <a href="http:&#x2F;&#x2F;github.com&#x2F;tinspin&#x2F;rupy" rel="nofollow">http:&#x2F;&#x2F;github.com&#x2F;tinspin&#x2F;rupy</a><p>2) For clientside: mostly C syntax (compiled with C++ compiler) is your best option and I recently made a in-app debugger for Windows: <a href="http:&#x2F;&#x2F;move.rupy.se&#x2F;file&#x2F;stack.html" rel="nofollow">http:&#x2F;&#x2F;move.rupy.se&#x2F;file&#x2F;stack.html</a> (this delivers something much worse than a Java stacktrace but as good as it gets without a VM).<p>I also hot-deploy the C&#x2F;C++ app code with a .dll to my .exe and the debugger works for that hot-deployed .dll too!<p>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&#x27;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!<p>Potentially I can hot-deploy the client .dll&#x2F;.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 (¯\_(ツ)_&#x2F;¯), but still really exiting!
knuthsatover 4 years ago
Tools and stuff around the code will still not allow an effective environment.<p>Code design is a huge bottle-neck. I&#x27;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.).<p>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).<p>I guess existing developers can be effective in this kind of environment but getting new ones to contribute will still be a chore.<p>Although, even existing ones, when they forget what they did, start getting difficulties creating new functionality.<p>For example, the biggest issue I&#x27;ve seen is &quot;dependency injection&quot; mindset. It&#x27;s a mindset that dependency injection library solves the dependency issue and you can just inject anything you need anywhere.<p>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.
leghiflaover 4 years 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.<p>I have seen developpers &quot;coding to the test&quot;. 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&#x2F;states of the system. This &quot;coding to the test&quot; can appear very fast with a quick feedback loop, making possible to &quot;monkey code&quot; 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.
bob33212over 4 years ago
I call this &quot;silver bullet consulting&quot;.<p>The reality is that their customers have slapped a developer title on anyone willing to take their 80k&#x2F;year job. And then they hire &quot;product managers&quot; who fill out schedules with arbitrary dates. Then when &quot;dates are missed&quot; 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.
shepherdjerredover 4 years ago
How do you convince management to focus on improving workflows? There&#x27;s often a huge focus on shipping features with that being the primary criteria for promotions.
评论 #25800244 未加载
评论 #25800153 未加载
评论 #25800095 未加载
logifailover 4 years ago
Q: Does anyone else find the body text hard to read?<p>Small and light grey text on a white background really doesn&#x27;t work for my aging Mk I eyeballs.
logicalmindover 4 years 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&#x27;ve found particularly helpful?<p>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&#x27;t overly cumbersome.
评论 #25800727 未加载
0xbadcafebeeover 4 years ago
What I love about shit like this is they&#x27;re walking around going <i>&quot;If you do X your productivity will increase.&quot;</i><p>Assuming this is true, you&#x27;re still fucked, because nobody can force your executives to then force their employees to do X. If the executive doesn&#x27;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&#x27;t, for the same reason nobody below them is doing it.
g051051over 4 years ago
&gt; Very sensibly, most companies are on a journey towards achieving this environment<p>Yes, until they realize how much of a crock it all is, and go back to actually getting work done.<p>Backstage looks interesting though, so maybe I&#x27;ll get something good out of the article.
lrossiover 4 years ago
So CI, automated tests, SCM, small patches, API docs, stand ups and the ability to take breaks.<p>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.
kohlermover 4 years 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.