5 ms·
The principle behind being a 10x programmer is not working more, but working less and using tools that multiply you. The 10x dominates the tools ( and techniqu
by cracrecry 4y ago
The principle behind being a 10x programmer is not working more, but working less and using tools that multiply you.
The 10x dominates the tools ( and techniques and people and capital) that multiply her.
If you have a car you can easily and consistently go 10x faster that walking pace. The same applies for your job.
Working on a given company, with access to capital and people and tools can multiply you.
- deleted 4y ago[deleted]
- mjburgess 4y ago10x is about the meta, and meta can be the tools (or frameworks, metaprogramming, etc.).
- erikerikson 4y agoOr good judgement and focus.
- mjburgess 4y agoSure, by meta I meant to include any system whose target is programming -- whereas programming has as its target the problem domain. 10x is systems for the system, including good judgment
- lawn 4y agoBut to become a 10x programmer I think you need to put in more effort than if you "only" do your job.
- ratww 4y agoSure, but putting more effort doesn't necessarily means working more hours. "Work smarter not harder" also applies to improving and applying yourself.
- wvenable 4y agoTo be more than a 1x programmer, you have to work on things that are not the most immediate goal all the time. This isn't necessarily more effort, it's just different effort, and will not have immediate positive outcome for your company. All the biggest and most important productivity and outcome enhancing things I've done at work have been done without management knowledge or approval.
- mbrodersen 4y agoNot at all. To be a 10x programmer you need to be lazy. Automate everything, brutally eliminate complexity, and focus 100% on what makes sense from a business point of view.
- Aperocky 4y ago10x is a really bad term, it tries to quantify a difference without a baseline. The difference isn't in quantity, but imo rather in mentality. Relentlessly automating repeatable tasks can net 100x or 2x or 0.5x depending on context, but something that don't happen often enough.
- ratww 4y ago> 10x is a really bad term, it tries to quantify a difference without a baseline. I believe this is incorrect. The baseline (or 1x) is the lowest-performing member of the team. At least that's how I learned the term.
- sokoloff 4y agoThe lowest performing member of your team could be negative. Or they could be twice as good as the lowest performing person on some other team, or they could be above the industry average, meaning a 10x programmer becomes a 5x or 20x when the team changes. I’ve always internalized as a “typical, competent programmer” rather than team-specific anything (Peopleware’s definition notwithstanding).
- astrange 4y ago10x implies there should be an opposite of a 10x, but it's unclear if that'd be a negative number or a 0.1x.
- imron 4y ago> but it's unclear if that'd be a negative number or a 0.1x A negative number. A 0.1x programmer gets work done acceptably but is slow. A negative programmer on the other hand creates more work for other people to fix, and you’d be better off not having them touch the code at all.
- drBonkers 4y agoWhat are the tools to multiply yourself in a software development setting?
- sokoloff 4y agoManaged services. S3 instead of building a process to store and replicate files on a file system that you manage. DynamoDB or RDS instead of managing your own DB. Libraries instead of cutting your own code for everything. Effective searching for projects who have already done the thing you’re about to do. Sometimes: it’s as simple as taking a day or few days to think the problem through to ensure you really understand it. Finding a way to deliver the needed functionality in Excel/Sheets instead of a custom application.
- jensvdh 4y agoCI/CD and more broadly building abstraction layers and automation.
- mediascreen 4y agoI often find that developers with an interest in product development and the business side can make huge contribution by suggesting alternative solutions to writing more code. With some gentle pushback on requirements they can help clarify what the real issue is. Of course, this has to be done carefully or it will quickly get very annoying. Another useful skill is to have a feeling for when problems get too hard and it's time to backtrack. At least in my work, most of it is basic CRUD of different varieties. If I find myself inventing new things or not finding any answers Googling my problem, it's likely that I'm on the wrong track and there is a simpler path I missed.
- mbrodersen 4y agoRemoving complexity and making the solution super simple can easily make you 10x or 100x more productive.
- imron 4y agoDon’t check hn, reddit, facebook, twitter or any other socials during work hours.
- torginus 4y ago10x can come from many different places, a few examples: - Person A gets assigned a bug, that there is a memory leak in the library, they are familiar with the code, they open up the profiler, see that there's an excess of Object X, they look for all the allocations, and see that it's not freed in one of 3 places. Whereas Person B does not really have a really good grasp on how either a library or the profiling tools work and mulls around, perhaps has to ask for help, and takes a lot more time. - A is confronted with an algorithmic challenge, they figure out an elegant solution in 1 hour, they think it through really well, the solution is flawless the first time. B takes more time, say 2x, and still are not sure in the solution. They implement it nevertheless, and pass it onto QA, who finds bugs, and the issue needs to be reconstructed, the code rewritten and retested. These things compound and add up. - Writing tools instead of doing things manually as others have pointed out - Using a library meant to solve a problem instead of rolling your own All these things are based on concrete experiences that happened to people around me.