TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

What makes developers productive?

187 点作者 piinbinary将近 2 年前

34 条评论

siliconc0w将近 2 年前
Business leadership is technical, they create the requirements with technical leaders, those leaders build out the roadmap. I don&#x27;t believe in &#x27;agile&#x27; 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&#x2F;no-go decision within a week.<p>The small team should have a lot of support in terms of an infrastructure platform, strong culture and tooling for development&#x2F;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.<p>After the &#x27;chunk&#x27; 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.
评论 #36748849 未加载
评论 #36749024 未加载
评论 #36748824 未加载
评论 #36751972 未加载
评论 #36751791 未加载
评论 #36753986 未加载
评论 #36759904 未加载
28304283409234将近 2 年前
Stop being productive. Just stop. Stop this insane qualification. Stop this forever-measure. This race for immer besser, always better. It is so saddening.<p>I came into tech for the joy and the wonder. You don&#x27;t measure joy. You enjoy joy.
评论 #36748388 未加载
评论 #36748666 未加载
评论 #36748449 未加载
saqadri将近 2 年前
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.<p>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
评论 #36749659 未加载
lordnacho将近 2 年前
I don&#x27;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&#x27;s definitely non-linear in the sense that it would be great if it were super fast but if it&#x27;s already slow, being a little slower doesn&#x27;t harm much. With all the tooling, there&#x27;s a distinction between fast enough to use synchronously and so slow that you need a reminder to come check the results.<p>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&#x27;t need, writing code that won&#x27;t be used.<p>Another thing I&#x27;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.
评论 #36754308 未加载
anotherhue将近 2 年前
&gt; 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.<p>Listen, I&#x27;m an infra guy, so maybe this hit a nerve, but &#x27;othering&#x27; infra because it&#x27;s inconvenient has got to stop. Infra serves many masters and you are probably the most flexible of them -- that&#x27;s why there&#x27;s so much push back.
评论 #36748286 未加载
评论 #36748251 未加载
mikewarot将近 2 年前
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&#x2F;VBA, Excel, Delphi, etc.<p>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&#x2F;B test to make sure your code works correctly compared to their reference&#x2F;spec.<p>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.
评论 #36757916 未加载
nathell将近 2 年前
There’s one more thing, for me by far the most important: mental wellbeing.<p>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.
评论 #36750157 未加载
评论 #36749052 未加载
评论 #36749254 未加载
tekkk将近 2 年前
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.<p>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.<p>Treating developers as monkeys who&#x27;ll do as dictated doesnt really sit well for many of them.
nickd2001将近 2 年前
I dispute &quot;slow tools&quot; 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 &#x2F; hang laundry out, as result feel refreshed and&#x2F;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. ;)
评论 #36756156 未加载
meesles将近 2 年前
Hey everyone, this isn&#x27;t an Ask HN. There&#x27;s an article with many of the points to discuss:<p>Knowing what to build, Doing fewer things, Tooling that reacts quickly, Knowledge in the developer’s head, etc.
评论 #36748262 未加载
gv83将近 2 年前
given my current reality ~ an obscene company that marketed itself as super tech driven then it&#x27;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.<p>it&#x27;s incredibly discomforting to spend even 10 minutes building things the other party clearly doesn&#x27;t want, but since everyone is a bloody &quot;head&quot; or &quot;chief&quot; of something, no one ever clearly defined upstream-downstream relations between teams. There is a lot of infighting and parleying over everything.<p>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.<p>the pay is decent (for where I live at least; it&#x27;s a &#x2F;10 from the &quot;500k tc&#x2F;1 yoy&quot; reality of usa, and i have like 10 YoY, even if I worked in very modest places so not many big challenges), and i&#x27;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&#x27;m counting the days until I can finally let go of those cretins, even if I have to stay a couple months without work.
synergy20将近 2 年前
To me it&#x27;s not about management or whatever, it&#x27;s about profit sharing.<p>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.<p>HR: What&#x27;s your dream about your job here?<p>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)
评论 #36751821 未加载
Joel_Mckay将近 2 年前
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.<p>There are some people that are clearly into S&amp;M, that proudly bring their kinks into project design.<p>This is extremely funny, because we all know this is actually true =)
评论 #36748781 未加载
CoastalCoder将近 2 年前
Purpose.<p>If I feel like there&#x27;s a small chance of my commit being accepted, or ever mattering, it&#x27;s hard to fake the motivation to work on it.
评论 #36749083 未加载
评论 #36751233 未加载
评论 #36748822 未加载
oldtimerherez将近 2 年前
It&#x27;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.
codingdave将近 2 年前
&gt; 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.<p>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.
评论 #36748618 未加载
评论 #36748384 未加载
TheAceOfHearts将近 2 年前
The real answer for a large number of software engineers is amphetamines and other stimulants.
评论 #36751532 未加载
dgant将近 2 年前
The easiest way to be unproductive is to make something nobody wants. I&#x27;ve seen a lot of dev time spent on products where nobody bothered to validate their need at much less expense.
perpil将近 2 年前
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: <a href="https:&#x2F;&#x2F;godspeed.run" rel="nofollow noreferrer">https:&#x2F;&#x2F;godspeed.run</a>
baus将近 2 年前
As a manager I&#x27;m going to throw in some more &quot;fuzzy&quot; ideas -- shared purpose and team identity. Also recognition of milestones and accomplishments
评论 #36756161 未加载
评论 #36748598 未加载
dboreham将近 2 年前
Doors. No meetings.
svilen_dobrev将近 2 年前
somehow the (developer&#x27;s) Fun is always left out of the functionality--time--price race. All them things in the article - yes, but if it&#x27;s no fun (even little) working all that, wontdo.<p>And the definition of fun can be elastic, but.. it has to be there.
jmorenoamor将近 2 年前
Proper tools Proper environment<p>For me, it&#x27;s zero friction from problem solving to actual running code.
评论 #36748270 未加载
kramerger将近 2 年前
&gt; Knowledge in the developer’s head.<p>&gt; Tooling that reacts quickly.<p>&gt; Helpful infrastructure<p>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.
FlacoJones将近 2 年前
Time to Release<p><a href="https:&#x2F;&#x2F;justkeepclicking.io&#x2F;whats-your-ttr-equation&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;justkeepclicking.io&#x2F;whats-your-ttr-equation&#x2F;</a>
engfan将近 2 年前
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.
stonecharioteer将近 2 年前
Clear requirements. Tell me what a particular feature is supposed to do damn it.<p>I want I code, so just let me focus on that.
deterministic将近 2 年前
Managers who have a clue and are not anti-productive. I have very rarely encountered such creatures in my 30+ years career.
pipeline_peak将近 2 年前
Getting something to work well enough today as quickly as possible so you can move onto the next ticket…… :(
robotburrito将近 2 年前
For me a lot of it is honestly just feeling like I’m appreciated.
nathants将近 2 年前
a decent laboratory, health, curiosity, and joy.
agumonkey将近 2 年前
Anybody researched CMMI ?
评论 #36749306 未加载
Incipient将近 2 年前
Caffeine
roandepoan将近 2 年前
ChatGPT
评论 #36748542 未加载