1. 47

JIRA doesn’t lie: I’m the slowest engineer on my team. I’m frequently the person who brings the least amount of points to “release” per sprint, which means I’m providing the least amount of value to the company on my team. This obviates both raises and promotions, and just generally feels shitty. My quality is not bad, but not necessarily better either. This all leads me to this:

What was one thing that made you a faster/better developer?

If you could give one tip on how to ship shit faster to a non-senior engineer, what would it be?

And because I know myself and our community well: Please, no keyboard shortcuts or text editor recommendations. 🙂


  2. 63

    First of all, equating “points” with “value” is a big and common fallacy you should reject, but I think other people will cover that much more eloquently than I can. So, my “one thing”:

    Slow down.

    Plan ahead before diving in. Take the time to build infrastructure. Do research, do cost analysis, do risk assessment. Make decision tables and sketch out state charts. I’ve even started writing outlines of programs in a notebook before vimming out the code. As long as you’re thinking ahead.

    This helped me far more than any other advice I heard. I don’t write code as fast as I used to, but overall I’m a much more productive developer when I move slow.

    1. 29

      What was one thing that made you a faster/better developer?

      …working for a company (Amazon) that treated code like a liability and encouraged solving problems with the minimum amount of it - like preforming surgery with the minimum number of incisions.

      1. 4

        treat[…] code like a liability


        @pab: Go sit down with whoever does operations for your team/org/company and watch how they work. You’ll learn why those tools written in the 70s are still on your laptop today, and how you can use them to solve some problems much faster and more reliably than other developers on your team can :)

      2. 8

        Velocity is a by-product of quality. And quality only comes when you think deeply about what you’re building, which requires that you escape the frenetic move fast and break things ideology.

        Aim to write code that’s good enough not to return to unless requirements change. Because then you can focus deeply on the next thing at hand.

        1. 3

          First of all, equating “points” with “value” is a big and common fallacy you should reject

          Don’t tell me—tell my manager! 😉

          In all seriousness, the things you are suggesting sound like they’re outside the scope of my job role (the things you listed are normally dictated down to me). Perhaps taking on more responsibility or pushing back may unlock some knowledge?

        2. 23

          TDD katas: after a few exercises at a local meetup, I gave much more mental structure to my development loop and this resulted in more effective development. This has nothing to do with applying pure TDD, that in my field is really hard to do (machine learning engineer)

          Not giving a fuck about deadlines: the stress from pressure made me do things in an unstructured, hacky way. This led to less mental clarity and worse code that had to be fixed eventually. I never failed a deadline anyway. Mostly because I can always outmanouver the PM and get it postponed if I got the estimates wrong, but with more structure, you learn to estimate better.

          My boss gets a dollar, I get a dime

          I don’t give a fuck, about the deadline

          Studying Clojure: I’m not sure about this. For sure it helped with clarity and framing small problems in a better way, thinking more about data and code and less about implementation details. Mind that I work mostly in Python.

          1. 7

            Clojure was also a big step forward for me as a programmer.

            Couple of reasons:

            1. Whole language/community dedicated to trying to remove the noise and solve problems directly.
            2. With Lisp you get access to a long history of programming ideas.

            I write iOS apps for work and I still use Clojure sometimes to prototype or wrap my head around a problem.

          2. 22
            1. Document everything about the issues you fix. It can be used as reference in future and when you look at the tasks you accomplished it will make you feel good.
            2. Ask for help. Don’t get stuck in a problem for a long time. If you are stuck in a problem for more than 2 hours it’s better to ask someone’s help.
            3. Focus on important tasks first. You don’t have to check/reply mails as soon as they arrive. Try to apply 80/20 rule.
            1. 4

              Even with a low threshold for asking for help, it can be hard to tell if you are stuck or not. If you work with solving hard problems, they all feel like you’re stuck until you have solved them, and they all take time to solve.

            2. 21

              That’s a good question! Here is a quick braindump, happy to provide more information on all of these points.

              Basic physical needs

              IQ and focus are affected by these things:

              • get enough (~8h) sleep every day
              • stay hydrated
              • exercise cores / cardio a bit
              • (personal) meditation to improve focus / self awareness
              • (if possible) find a good work environment

              creating good automatism allows to go faster and not break out of the flow

              • comfortable dev environment, that’s very personal
              • logical git commit
              • do one thing after the other. multi-tasking gives the impression of work but is very inefficient.
              • use a binary search approach for debugging
              • learn to say no nicely (some people try to push their work onto you)
              • learn to create focus times in the day with no interruptions

              Learn how things work to be able to think on first principles. StackOverflow doesn’t have answers for everything.

              1. 5

                This is a great post and the advice here is greatly underrated in our industry. The difference in my quality of work on a day where I’ve had 8 hours of restful sleep vs. a day where I had 6 hours of sleep and am dehydrated, or have a lingering cold, or something similar is dramatically more than you’d expect. Everyone sort of accepts that if you have a migraine, or the flu, your work will suffer. But even the littler things make a big difference when you get to the (for me anyway) very high-level intellectual utilization that programming demands.

                As a process thing, whenever possible I like to create a personal branch and make a series of small commits as I go, knowing that I will squash them into more logical groupings before merging my work. This lets me experiment with a direction reversibly without forcing my peers to see 25 commits over a single workday.

                I’m also a big fan of carving out uninterrupted blocks of time (no meetings, chitchat, chores, etc.) but as I work fully remote this is likely both easier for me as well as more desirable to me, assuming people to some extent self-select into fully remote work.

                1. 1

                  Thanks! If only I could post this to myself 10 years ago :)

                2. 2

                  use a binary search approach for debugging

                  What does this mean?

                  1. 5

                    I assume somewhat like git bisect, e.g. we know that version/commit 30 has a bug, we know that version 10 didn’t. Rather than checking version 29, then 28, etc. instead check version 20 (preferably automatically, with a regression test). If it works, check version 25, and so on. This can make narrowing down issues much easier, especially when (a) every commit can be checked (e.g. it always compiles successfully, doesn’t crash during initialisation, etc.; this can be enforced with things like pre-commit hooks) and (b) the commit history has lots of small commits, rather than e.g. squashing large changesets into a single diff.

                    Note that the same approach can be taken when printf debugging, or stepping in a debugger: check the state near the start/input part of the code, check the state near the end/output part, and check the state roughly half way through the processing. This narrows down the problem to one half of the program/trace. Add checks roughly half way through the dodgy half, and iterate until the problematic step is found. This can be more efficient than e.g. stepping through each statement one after another; or reading page after page of logs.

                    1. 4

                      I assume somewhat like git bisect

                      Ah, I wouldn’t exactly call that debugging. Debugging, to me, is the step that comes after finding the problem commit, if there is such a thing.

                      Note that the same approach can be taken when printf debugging, or stepping in a debugger

                      Mmm-hmm. All fine until it’s race conditions you’re debugging. My week at work..

                      1. 3

                        Mmm-hmm. All fine until it’s race conditions you’re debugging. My week at work..

                        Yeah, consistently reproducing an error is an important prerequisite, but sometimes the most difficult part!

                        1. 1

                          Ah, I wouldn’t exactly call that debugging. Debugging, to me, is the step that comes after finding the problem commit, if there is such a thing.

                          In that case, you might still not “get” what’s happening. In that case, if you can figure out your input, the expected output, and what the output actually is, you have a good starting point.

                          From there, if you are judicious about choosing what part of the input to vary, you can quickly eliminate classes of problems. “Oh, the username probably doesn’t matter here because this shows up all the time”, “ah turns out that it’s this inner function that is returning problematic data, so stuff after it might not be the cause”

                          Draw a circle around the entire state of your commit, and then find ways to cut off huge chunks of it until you’re certain that the bug is in what’s left. If you’re not rigorous about this it doesn’t work well, but if you figure out “logical certainties” you’ll likely quickly isolate the bug

                          (This is part of why TDD works well in debugging. You found a snippet of code that is misbehaving. You dig deeper until you find a minimal problematic snippet. A quick refactor to place that snippet in its own function, and now you have a test case!)

                          1. 1

                            Yeah, I keep thinking race conditions. Where you could draw multiple circles that all converge at different points, all points being code that is obviously correct. The commit is right, it’s just probabilistically exposing the presence of a bug somewhere else in the code base. And that’s why TDD doesn’t work, because the bug isn’t in the minimal problematic snippet.

                            1. 1

                              I’m not real sure what your race conditions looked like, but you could maybe synchronize everything in a program (wrap mutex, log access, &c), or synchronize nothing, or something in between. That would be sort of binary searchable, or at least div-&-conquerable.

                              You’re not writing Go, by chance, are you?

                              1. 1


                      2. 5

                        Not sure this is what OP mean, but it reminds me of the approach I take to debugging. Your goal is to come up with a hypothesis that cuts the search space in half. Think through what could be causing this bug and try to falsify each possibility. This talk by Stuart Halloway does a good job explaining the approach. https://www.youtube.com/watch?v=FihU5JxmnBg

                        1. 2

                          Binary search is an algorithm that allows to find the solution in O(log(N)) attempts. It’s the same algorithm used by git-bisect but it can be used in the real world as well.

                          It’s part of the discipline because it forces to make assumptions and probe the extremities first instead of trying things randomly. Usually it’s possible to make assumptions about the bug location. Split in the middle with some debug statement, find which side is broken. Loop.

                      3. 16

                        Unit testing, auto-test on save, and working in very very small increments.

                        1. 14

                          Far as faster, there’s a lot of data saying languages with instant feedback on what the code does and quick changes are better. Lets you operate in a state of flow where you have the stuff in your head moving with maximal efficiency. Flow is covered a bit in must-read PeopleWare. Buy it and read it.

                          On language side, it can still be safe, have contracts, have verification tooling run overnight, have compiler optimizations done later, or whatever. You just need to be able to quickly write, explore, and fix your programs in it in some mode. LISP’s and Smalltalk dominated this niche in the past. Much of the designs for this stuff today are using scripting languages or targeting JavaScript. The mastery-level approach is to use something with productivity of scripting languages that cranks out high-performance, release code along lines of C or C++. There’s more options for that than there used to be now.

                          1. 6

                            Instant feedback via ghcid + strong type system is probably the reason I love writing Haskell. I don’t even like the syntax much, but it doesn’t matter because those two things enable very high productivity. I spend much less time screwing around tinkering trying to get things to work.

                          2. 13

                            If you notice you keep going back to your code to fix bug after bug, I would recommend writing code and unit tests in lock step (some people would call this TDD, but I don’t go all in on this philosophy). This will initially slow you down (especially if you don’t have a test harness set up yet), but it will make you more productive in the long run, as you will not keep fixing and re-fixing the same bugs. Every time a bug is found, write a regression test that triggers it and then try to fix it. This way you won’t spend time spinning your wheels on the same code.

                            I also find tests help me to iterate quickly on difficult code; I will sometimes start with a tiny unit test and expand on it as I explore the problem. Manually exploring in a REPL can help too, but for some reason just running a script feels easier and more reproducible to me.

                            If your code is well-factored (and tests can “force” you to make it so), it becomes easier to debug or replace parts in isolation. For example, while I work on web backend systems which are callable from an API, sometimes I like to write the internal API such that I can also easily call it from a command line task. This allows me to quickly iterate and compare the results; if you write debugging info to stdout/stderr and redirect it to a file, you can diff the results if you tweak things here and there. For very complex tasks this can be a lifesaver: you can quickly dive in and inspect intermediate output or components separately.

                            Asides from that, take the time to learn your tools well. Knowing some (possibly obscure) option of your framework, language or database can occasionally be the difference between hours of struggle and a few minutes of work. Investigate in the available debugging and performance analysis tools. You don’t want to know how often I’ve seen people write buggy, slow code to insert or update records in a database from their programming language which could be done faster and more reliably with a single query. Even learning something simple like automated “git bisect” (where you pass a script that determines if it’s a good or bad build) can save you tons of work. Same goes for other basic UNIX tools like grep, find, diff and such.

                            Finally, work on your theoretical fundamentals. For example, knowing the basics of complexity theory can make the difference between writing terribly slow code and writing fast code.

                            1. 13

                              The cynical (but true) answers:

                              1. Work on “greenfield” projects. Never maintain anything. The first line written in a module is always 100000x more code than an empty file.
                              2. Promote whatever you write. Any person you get to use your code is a justification to continue working on that.
                              3. Write your own requirements. It is easier to meet deadlines if you are supplying what you already have.

                              The true (but hard) answers:

                              1. Do not develop fast, develop correctly.
                              2. Code, like art, is never finished, it is only abandoned. Think about the person who is going to extend/modify your code after you abandon the project.
                              3. Get a lot of feedback from the person that is going to sign off whatever you ship. They are the ones that can say if you “shipped shit” or you did not. Much more telling than JIRA, in the end.
                              1. 11

                                Tools tools tools. Taking a loooot of time to get really good with your tools, understand build systems very well, DRY in your IDE, automate stuff, learn about make/ant/maven/gradle/whatever the kids use these days, be able to setup/pull down/reset your dev environment with automation as fast as is possible.

                                Sort out that debugger that you never got working properly so you had to put in shitty debug code. Do you keep doing something in your IDE? Find the keyboard shortcut. Make scripts to establish a clean dev environment insanely fast.

                                The best 10X developers I ever worked with seemed to have magic incantations that did things like setup a fresh dev environment in seconds, or a shortcut to load the help page for a particular command/syntax almost instantly, or magical powers over ant/maven, and always had some personalised quirks like decked out IDE that got them ‘at the coal face’ of the actual programming problem insanely rapidly, or weird keyboards, or weird window managers.

                                Takes time, but pays huge paybacks in the long run.

                                1. 8

                                  Personal anecdote, I had the luxury of a lot of time to setup a personal dev environment recently for a python project, and so far have spent about 50% of the time on the environment: vscode with python plugins that integrate with a venv. Properly understanding and utilising venvs and managing versions of python. Scripting all the stuff I do to establish the dev environment and start my IDE ready to code. Automatic instant code replication between a local and remote dev server that takes ~1 second to sync changes so I can instantly test in a larger dev environment (and use the same dev environment setup scripts in both places so I know the environment will be the same). Script to automate the database dev setup.

                                  Toooooootally paid off: programming is fun again.

                                2. 11

                                  I can’t keep this to one thing, sorry.

                                  Go slow & correct first. Pre-requisite to be able to eventually go faster and correct.

                                  Learn new languages. Helps with thinking about problems in different ways.

                                  Short feedback cycle! Anything that improves this will make you faster – TDD or at least test first development, and Continuous Deployment are big ones.

                                  Spike and Stabilise pattern (this and more related good stuff by Dan North in https://leanpub.com/softwarefaster)

                                  Pair programming can sometimes make you faster and better, depends on the problem and the pair.

                                  Drawing things (whiteboard or pen and paper) can help a lot

                                  1. 8

                                    First of all, JIRA doesn’t lie or tell the truth. It just is. Points don’t tell you value, they tell you an estimate of complexity. Using points as a relative measure between engineers doesn’t lead to good things, which it sounds like you’re already seeing. I’ve got a bunch of questions like “are you the one estimating the points, or is your team” and stuff like that, but I’ll skip it for now.

                                    The thing that made me move fastest was creating giant blocks of “CODE” on my calendar. I don’t mean meetings though they occupy the same space. There’s just a huge, multi-hour chunk of time where I’m by myself writing code.

                                    Generally speaking this is really hard to achieve at my current job. Now that I’m a team lead, everyfriggenbody wants to have a “quick” 30 minute or 1 hour meeting, but I can ensure my team members are - whenever possible - spending like 4 or 5 hours a day writing code uninterrupted by anyone. If they need to reset their brains by grabbing a coffee or taking a break to chat around the water cooler for half an hour, no biggie, but if they’re in the zone? They need to be left alone.

                                    I would also look at what the other engineers are doing. Look at their commit history: see the changes they made for their story. How did it evolve? What did they have to do to get there?

                                    1. 12

                                      Keep in mind Angersock’s Law of Rapid Development:

                                      It is okay to ship shit as long as shit ships.

                                      This is mainly if you’re doing web dev, but the thing I’ve seen is that users put a higher premium on rough but available tools than on correct but distant ones. Get your first rough cut in front of people and have them use it, and keep piling on mud until they’re happy.

                                      As long as the happy path mostly works your software is shippable. Guards, better UX, and clean code can all come in time.

                                      1. 9

                                        Depends on industry…. In a deeply embedded system where product recall means return thousands of vehicles to base…..


                                        Just plain no.

                                        However, if you mean “ship a reduce set of features, as long as the features ship (and have value to the customer)”.

                                        Yes, by all means.

                                        1. 3


                                          If the industry is not webshit, don’t follow that rule at all! Similarly, if you are making libraries or other artifacts that will outlast you, don’t develop that way.

                                      2. 7

                                        A thing that has helped me tremendously, I think, was getting into a practice of documentation.

                                        On the one hand, a thing you can start right away is keeping track on the ways you spend your time on a given task — how much of it is research, vs. debugging, vs. trying things out, et cetera. This can give you insight into your day and guide your efforts for improvement.

                                        On the other hand, documenting the things you learn — either along the code as comments, or into separate documents (e.g. “Today I Learned” type of repositories, see this thread for inspiration) — can give you, on the longer term, a wealth of knowledge you can refer back to. It has never ceased to surprise me how easy it is to forget how to do things in a year’s (or even a month’s) time, and I have never regretted documenting anything.

                                        Another super important thing is to ask for help when you get stuck, because that’s when things go sour. Ask for advice, do pair programming, anything that can get you back on track, instead of procrastinating / agonizing about a problem for too long.

                                        1. 6

                                          I don’t think there was ever /one thing/ for me. Improving comes from introspection. Try finding your flaws, fix them. There’s various things to read. Start with Julia Evans’ recent’ post on being a senior engineer, followe the links. Maybe read the first linked article on the mature engineer.

                                          Good luck on your future endeavors and P.S: if I absolutely had to recommend only one specific thing it would be communication. It’s the key to everything.

                                          1. 6

                                            This is a great post and a great question and could be fodder for a whole book.

                                            Process items:

                                            • I stack the deck by picking interesting projects. If I’m bored by a project, I don’t do it as well
                                            • avoid tarpits by speaking up if assigned unreasonable tasks.
                                            • consistently break down large stories into small, discrete tasks. this gives everyone a sense of my progress and cadence
                                            • working closely with the other folks on the team. If our pieces of code need to mesh, we need be on the same page, the sooner the better

                                            Technical items:

                                            • I use strongly typed languages that help me prevent bugs by using things like exhaustive pattern matching
                                            • where ever possible, I write total functions and avoid partial functions
                                            • Good testing / CI hygiene - I write tests that run with the build
                                            • I avoid mutation because I’ve found it to be a large source of bugs
                                            • I outsource the things that I’m not good at. Whenever possible, I use managed solutions like Heroku/Elastic Beanstalk, RDS, Cloudfront. (instead of managing servers and databases)
                                            • I asked for, and received superior hardware. My work desktop has 8 cores and 32 GB of RAM
                                            1. 2

                                              another thing: productivity is a function of you and your environment. If you take a great engineer and put them in a terrible environment, they may be far less productive than a average engineer in an excellent environment. But at the next level are people who transform their environment to make it better, more supportive, more productive, more fun. But that’s a whole other subject!

                                            2. 6

                                              You’ve gotten a lot of good feedback here but I’m going to throw in my own 2 cents because I’m not sure the most important points have gotten enough attention:

                                              I’m the slowest engineer on my team. I’m frequently the person who brings the least amount of points to “release” per sprint, which means I’m providing the least amount of value to the company on my team

                                              Your value to the team should not be measured merely in points. If that’s the way your manager is doing it, your manager sucks, go get hired somewhere else, only this time be sure to ask in the job interview how they measure employee performance.

                                              Development is not my main job but I’ve done a fair mount of it. I’m not a fast developer. I’m not a fast anything. Any time I solve a problem, I take the time to understand the bigger picture in which that problem fits and then I craft the best solution in that context. This puts me “behind” others in an environment where looking busy and productive is held to a higher standard than providing actual value. And that’s fine as far as it goes, I’m just careful to either prove my value in other ways or I make a move somewhere else.

                                              It’s probably the case that you are in fact providing the same amount of value to the team as everyone else, it’s just that these “points” don’t reflect it. For example, your work may higher quality on average. Or your team members might be better at picking stories with higher points that they know they can do quicker. Or they just simply might have more experience than you and you will eventually catch up.

                                              1. 5

                                                Getting used to the tools of my environment instead of passing in front of them ignoring their working helped me : The more curiosity I had about the language / project / tool internals or usage, the easier it was to switch from docentation to actual code to writing commits to reformatting the makefile.

                                                Also, it got way easier as soon as I dismissed the background feeling that I need to check a dozen of times if what I am doing is the right thing : instead, going from the problem, ifentifying if there might be alternatives in the solution, if not go ahead without thinking, if yes, make rationale decision about which ones without putting too much feelings with it.

                                                On the other hand, this may be much like doing all the technical sacrifices that permit me to jump to the next issue.

                                                A better thing that I would like to tend toward is to anticipate what the next challenge might be, by having the big picture in mind and designings all parts to fit altogether. This hopefully will help writing fewer, better code directly oriented toward solving the general problem instead of “running like a headless chicken” and solving the local issue in front of me which will lead me to a new one.

                                                The former way usually leads to more reward from current manager as it tends to much more code, but much less design and much less issues created.

                                                1. 2

                                                  On the other hand, much of my time was spent on figuring out where to go next. Stopping this by rationale decisions is not a bad thing I feel. All of this is highly personnal, but it is one more point of view.

                                                2. 4

                                                  A lot of voices here say, “Tools”, I will agree with that but say it’s understanding them rather than fluency that counts.

                                                  TDD is the fastest path to done done.

                                                  Active practice. I have a weekly reminder on my calendar to “Learn Something”. Something about a tool, my editor (emacs), programming. And there I try out some experimental idea.

                                                  No cargo culting, learn the reasons behind ideas.

                                                  Asserts. Not sure you understand something about the code? Immediately drop in an assert stating what you think is true. Let the compiler and the tests tell you if you are wrong. If you are not, downstream of the assert rely on it being true.

                                                  1. 4

                                                    JIRA doesn’t lie


                                                    1. 4

                                                      I had a colleague who when he was a newly minted programmer realized he wasn’t very good at writing lots of code quickly. So instead he focused on problems that required more thought and planning up front: frameworks instead of features.

                                                      Some of his colleagues are still doing the same thing they were when they started. He’s moved on to much harder and more interesting problems than churning out small features for a web app.

                                                      1. 4

                                                        The technique that worked best for me probably won’t work in your situation, because it involves a short (~6 months to a year) period of intense dedication to tasks that have no obvious short-term benefits. (In other words, it’s much easier to do when you’re still in school.) However, I’d like to mention it because it’s very effective, very counterintuitive, and almost never mentioned in this kind of thread.

                                                        The technique in question:

                                                        1. on your own, dive deeply into a wide variety of languages
                                                        2. try to solve problems well above your head (filling in missing information as you encounter it)
                                                        3. specifically try to solve problems using languages (and other tools) that are ill-suited to those problems

                                                        Every language encodes a mindset about how it should be used, even if it doesn’t explicitly enforce this mindset. This means that every language has a ‘royal road’ where programs are simple, clean, idiomatic, readable, and maintainable. At the same time, every language also has a ‘bush’ where programs are complicated, messy, awkward, incomprehensible, and fragile.

                                                        Learning materials stick almost exclusively to the royal road, but real problems happen in the borderlands, and without a deep familarity with the bush it’s really easy to stray off the road without noticing. At the same time, many languages have hidden similarities that can allow problems to be solved more cleanly than they otherwise would (because the bush in one language is the royal road in another & you can import techniques that are alien to people who aren’t familiar with both). Six months of varied but intense frustration is a great way to carve antipatterns into your soul so that you can quickly identify seemingly-reasonable decisions that will lead to a lot of unnecessary pain in two weeks.

                                                        Basically, this is a kind of aversion therapy. During this period of intense training, stimulant use, sleep deprivation, and poor diet is just as desirable as poor planning and tool choice. After all, the habits you have explored during this period should be avoided forever after.

                                                        Unfortunately, the intensity of this technique (which prevents it from being viable when you’re already employed or under other stresses) is totally necessary. When people make poor tool choices while working at a normal rate – even if the tool choice is both extremely & obviously poor – it just becomes a habit. (Look at whatever internal project has the most issues & see if you can figure out what language it should have been written in, or what development techniques would have resolved most of its problems. A lot of the maintenance work – perhaps even most of it – in this industry comes from people with a favorite hammer trying to hammer in screws. Identifying poor-fitting tools early saves team-years of work.)

                                                        1. 4

                                                          Learning to leverage types, a REPL, getting fluent with one editor (I don’t care which), learning how to quickly and efficiently share my screen for pairing with others on problems.

                                                          http://bitemyapp.com/posts/2018-03-14-how-i-stream-coding.html touches on some of what I use for pairing.

                                                          Writing logs as I debug problems is another one. I basically journal my thoughts, what hypotheses I have, what I’m observing, and why I may have changed my mind in the process. When I’ve exhausted the data I can pull/observe and the experiments I can run, I review my log. There’s several reasons this is important:

                                                          • I’ve discovered the causes of problems in the past solely because I could scan up and down my log.

                                                          • I can MUCH more efficiently and effectively bring a coworker or outside expert up to speed on a problem.

                                                          • Issues that have required debugging can now be checked into version control and searched in case a future problem arises to see if it’s a regression/repeat or if there are commonalities in the occurrences of the problems.

                                                          Related but different: I’ve also shifted away since about 2012 or 2013 from “debugging” as an act that requires an actual injected or interactive debugger like GDB toward observability. Especially WRT making extensive use of structured, queryable logs. My Road to Damascus moment on this one was realizing I fixed a problem with a Python parser after many hours of ipdb debugging in 5 minutes once I switched to using logs and scanned them with my eyes linearly.

                                                          1. 3

                                                            Points do not mean value of course, and they are not intended as a measure of individual developer speed, because scrum is about team capacity. Treating it in this way creates perverse incentives.

                                                            Probably you’re helping people “too much” and not getting enough help yourself. Pair, and get people to come help you get over any humps. That will help transfer points from them to you.

                                                            Secondly, try closing out tickets when the bare minimum of functionality is met (tdd will help here). If you can still earn points for bugs (which you should given that it’s being treated as an individual metric) then you can pick up points for fixing unfinished functionality.

                                                            Thirdly, look at where you’re burning time in your dev cycle: keep a detailed log of the time you spend. This will help you know what to optimize (which will frequently mean getting other people to contribute, or omitting much of that activity).

                                                            Finally, try to increase the points allocated to stories you are likely to work on. Do this both by picking those stories out during estimation and arguing for higher point values; but also by picking stories that you think are oversized.

                                                            1. 1

                                                              Treating it in this way creates perverse incentives.

                                                              It is always treated this way. Numbers are like sirens to the mind. We can’t help adding them and averaging them and doing all kinds of stupid stuff with them. That’s why I think we should avoid numbers while estimating things. If you think it’s hard, say it’s hard, luckily, the average of hard and easy is undefined. Whatever value you hoped to gain from numbers’ arithmetic properties was a false promise to begin with.

                                                              1. 1

                                                                No it really isn’t always treated this way. The only time I’ve ever used it this way was to try to quantify and capture the gap between good and underperforming team members. It was appropriate in that case because they weren’t creating value in other ways.

                                                                If personal point velocity has been used the same way OP’s company does everywhere you have worked, then that’s a huge problem and I would love to talk more to your management about it.

                                                            2. 3

                                                              Take the chance and opportunity to dive into the layers above your work developer interests & below your developer interests, for these reasons:

                                                              1. learning to incorporate new information quickly
                                                              2. being able to make decisions quickly (by having a mental model of the systems below/above you)
                                                              3. learning what concepts/practises are good/bad. You will notice goals/patterns repeated in different layers of your software system, i.e. how to do idempotency, or state management.

                                                              Also, understand how you software is packaged together: how dependencies are built, how your build-system does things. This has tremendous leverage for working faster through automation and identifying which parts are bottlenecks.

                                                              1. 3

                                                                How much do you want to be a better developer? What are you willing to give up in pursuit of this?

                                                                To start, you need to be able to look objectively at how you work and ask yourself, “is this really the best way to be attacking this problem?”

                                                                You cannot look at what everyone else is doing, unless you have excellent coworkers: the accepted practices of the industry are staggeringly mediocre at best. From a code quality perspective, people routinely defend massive coupling, poor cohesion, and balancing critical business logic precariously atop mountains of dependencies in the name of pragmatism. They compromise on quality, skip writing tests, and then brag about the fact that they shipped code without doing those things, perhaps as a way to signal the fact that they’re willing to subordinate their own pursuit of quality in the name of the almighty Business.

                                                                1. 2

                                                                  How much do you want to be a better developer?

                                                                  I have a really hard time focusing on code and liking coding, and I seriously wonder whether becoming accomplished within my team would cure me of both. In short: If it means I can finally enjoy my job, I would like it very much. 🙂

                                                                  What are you willing to give up in pursuit of this?

                                                                  Answering this personally, I feel like I’ve already sacrificed too much. Working 60 hours/week plus 24/7 on-call 1 week/month doesn’t give me a whole lot of extra time to become a better engineer without sacrificing hobbies or relationships. Plus, I’m studying at college to finish my degree at the same time.

                                                                  1. 7

                                                                    I just came to this. Seriously, 60 hours a week? Like, 12 hours a day Mon-Fri? Sustained over time? I honestly don’t know how anyone expects anything other than total crap out of you. I mean, sure, if 6 hours of that are surfing the web, then fine, but if so, why not just do 6 a day/30 a week of good work and do the web surfing at home? But if not, if that’s actual concerted effort, then it’s just not possible to maintain that level of attention and concentration and come up with anything of any kind of quality worth having, and you shouldn’t be surprised you’re finding it hard to be productive. I’ve done that kind of hours in stints, and while it’s manageable for a short period if there’s a very specific reason, longer term it’s just not sustainable. And I’m kind of a robot. Let alone 1 week out of 4 on call 24/7, on top of all that!? Seriously, that’s insane. Anyone who tells you otherwise is just lying in order to further their agenda. Seriously. Fuck ‘em. Quit. Find something else. This is literally just a recipe for burning out and destroying any confidence you have left (as you’re discovering). Fuck it. Nothing’s worth that. And sure, maybe other people are sticking with it and appearing fine, but … that’s their lookout. Screw that kind of peer pressure. Not worth it. Walk out. Work in Chick-Fil-A.

                                                                    1. 2

                                                                      Admittedly, I factored in commuting into that number. But yes, I leave home at 8am and get back home around 8pm. My actual “at work” hours are from 9am to 7pm. I clicked through to your website and see you’re in the UK—it’s (sadly) not terribly uncommon for these kinds of work hours to happen in the US, and especially in my area of the US (SF).

                                                                      Chick-Fil-A would not even come close to paying the rent, is the thing :)

                                                                      1. 4

                                                                        Well I lived in the US for 4+ years, including 2 in NY (with its nuts work culture) and a several-month stint in SF, so I do have a feel for it. And sure, Chick-Fil-A was an overstatement ;-) - but seriously man, there’s an agenda there of people telling you that you need to work those kind of hours, and it’s not even a smart agenda, because it genuinely does end up with less valuable output. Even 10 hours straight is too much, even with a 1hr lunch break. (Especially with the whole 10-days-a-year vacation thing, c’mon, seriously.) I mean, obviously, doing a few hours extra here and there because you’re into the thing you’re doing, or because there’s a deadline looming, sure, no biggie - but as a sustained timing, with that as an unspoken expectation (especially if it’s the unspoken kind), it’s just not worth it, and I think you should find somewhere else. But of course I understand the rent issue. It’s a fucker. Just worth looking into finding somewhere that is more realistic about what actually gets good results and ends up leaving people feeling like they’re valuable.

                                                                    2. 5

                                                                      That context changes things significantly. Balancing 60 hours a week (plus on-call obligations) with getting your degree, relationships, and taking yourself is a LOT. Do you want to be doing all of that? If the answer is no, I’m not sure if getting better at coding is going to fix this.

                                                                      I have a really hard time focusing on code and liking coding

                                                                      I would sit with this thought for a long while, however uncomfortable. If your discomfort comes from wanting to be better, then that’s a different thing entirely from, “I don’t want to be doing this type of work.”

                                                                      I feel like I’ve already sacrificed too much

                                                                      I just want to call this out to affirm it.

                                                                      1. 2

                                                                        Thanks for your response. I really do want to get better, because I need my job to pay for my degree and I get a lot of personal satisfaction around being good at what I do, even if my time as a developer is temporary.

                                                                        For context, I only take one class a semester which equates to about 9–10 hours/week.

                                                                        I would sit with this thought for a long while, however uncomfortable. If your discomfort comes from wanting to be better, then that’s a different thing entirely from, “I don’t want to be doing this type of work.”

                                                                        It IS uncomfortable 🙂. I’ve spent five years in this field and the idea of leaving is hard because the money is better than a lot of other professions. I took a career aptitude test recently and I got “Author” and “Astronomer”—both unrealistic careers IMO.

                                                                        The worst part though, by far, is that I used to love coding. If I could unlock it again it would solve a lot of problems for me.

                                                                        1. 3

                                                                          If you are motivated intrinsically by delivering quality software and meeting the needs of your users, you have some things you can chase down. Those two things are what sustain me working in a business software development environment. I try to ensure that at the end of the day I worked as best I could to my standards. Nobody can take that away from me. When I use practices such as breaking features into discrete modules, TDD, good domain modeling, and functional core/imperative shell, I move about as fast as I possibly can while feeling confident in the code I ship.

                                                                          On the other hand, if a shop wants me to shove all my code into Rails controllers and clean it up later, then I’m not a good fit for it. Because of this, I actively avoid certain ecosystems because they encourage this behavior.

                                                                          I hope this is helpful. Navigating career uncertainty is difficult and I wish you the best. Please let me know if I can be of further assistance.

                                                                          1. 3

                                                                            This has been extremely helpful—thanks so much for your response. 🙂

                                                                          2. 2

                                                                            So what was it about coding that you loved? And what is it about coding today that you don’t love? It may be that you are not doing the type of coding you love.

                                                                        2. 3

                                                                          This information is very relevant to the question, and changes the dynamic a lot.

                                                                          How many of these situations apply to your co-workers?

                                                                          If you’re the only person who is also going to college, then you’re going to be slower than your co-workers, they have less to worry about.

                                                                          I’d also look into ways that you can spend less than 60 hours at your job, unless there are other, good reasons to do so. That might involve time boxing things at work more, changing your estimates, and/or conversations with co-workers who aren’t on your team, or scheduling more aggressively for yourself.

                                                                          Without crazy drive combined with mixing up work so that it’s not always crazy hard stuff, and oftentimes even with both of these, working much over 40 hours a week will slow you down in the long run.

                                                                          I would spend some time thinking about why focus is difficult. Is it always difficult? Have there been situations where it isn’t, and if it wasn’t, do you remember why? What got you into software development in the first place?

                                                                          1. 2

                                                                            How many of these situations apply to your co-workers?

                                                                            Haha, that would be none of them. I find most people in our field are confused why I’m “wasting my money.” The reason I give them is that I’m future-proofing myself against an economic recession.

                                                                            I’d also look into ways that you can spend less than 60 hours at your job, unless there are other, good reasons to do so.

                                                                            This part is non-negotiable unfortunately—a cruel reality of a startup needing its next round of funding in addition to the more “performative” aspects of our field (leave after your manager, look busy, etc.).

                                                                            I would spend some time thinking about why focus is difficult. Is it always difficult? Have there been situations where it isn’t, and if it wasn’t, do you remember why? What got you into software development in the first place?

                                                                            It wasn’t always difficult. I for the first two years of my career I couldn’t stop thinking about coding. For some reason, once I moved to the SF Bay Area (three years ago) something in my head switched (whether it was the new job or new location, I am unsure) and now find coding pretty grueling.

                                                                            1. 3

                                                                              So, some thoughts I have, with a huge caveat that this advice may not apply 100%.

                                                                              Big picture thoughts:

                                                                              Well, I would consider a job or a location change long before I’d consider leaving the field, if only because being in this field gives you a lot of options for both. The working environment can change a lot about how things go.

                                                                              I’ve worked remotely and on-site and your manager and co-workers can make a huge difference in how your day-to-day goes. Do you have co-workers you can trust to try to work through these issues with? If the nature of the startup is such that there isn’t enough time to assess things at a deeper level than “I’m slower than my teammates” with your co-workers? A startup isn’t always the best place to try to grow skills as a developer, especially if you’re not motivated by the company’s vision, or how things are run. If you don’t have much scope to change either at the company, it might be worth considering finding either a different team, or a different company to work for. That’s not a move I’d take lightly, but it sounds like there’s a decent amount of disconnect between you and your job at the moment, and that it’s been going for a while long-lasting disconnect. I would especially consider this if you’re not in an organization where you have someone to help mentor/challenge you through the issues that might be affecting your productivity. A change of scenery can help a lot of things.

                                                                              Tactical Thoughts: If this is a long-term issue, it’s not going to resolve itself overnight. Some thoughts for the here and now (YMMV, I don’t know what all of this you’ve already tried) If you’re stuck with 60-hour work weeks, I’d make double sure that you’re also doing things to take care of your body, like getting short bursts of exercise (anything to get your heart rate up a bit), and/or getting away from your screen at least once every two hours. I’ve found that taking breaks is a good way to break cycles of distraction. Try to set up boundaries so that you have blocked out times (when not on call) of not having to think about work.

                                                                              Also, try mixing things up at work as far as approach goes. That might be problem solving on paper, it might be talking through things out loud, it might be tracking where you spend your time, it might be shifting the hours you actually try to do deep work vs lighter work, either so that you’re not distracted by co-workers, or so that. I also like to mix up the keyboard and mouse I use, personally, so avoid RSI from always being in the same posture. YMMV.

                                                                              Finally, if you can, ship something small, but meaningful, as a side project outside of work, and do it to the utmost best of your ability. It could be a single static page with a bit of Javascript that helps automate a small part of your day, or a desktop application that does something you need done. Not so that you’re accomplished, but so that you have a reminder that development doesn’t have to be done the way it is at your current job. If not, just remember that there are lots of other opportunities out there.

                                                                      2. 3

                                                                        I’m going to take the Stack Overflow approach here and suggest that your question is wrong :P

                                                                        Maybe you are underestimating point values in sprint grooming! Especially if, like my workplace, we do “agile” but it basically translates to “people just write their own stories and work on their own subjectmatter anyway” - it’s easy to assign points on a personal scale that isn’t reflective of how others would do it.

                                                                        Unless you’re actually missing closing stories on time, you’re probably pulling your weight. Maybe raise the question to Scrummaster / Project Manager and ask for their input on story sizing.

                                                                        1. 2

                                                                          Hey there! We point stories as a team, so the point value is derived from consensus.

                                                                          My stories frequently do not close on time—I feel like my PM avoids giving me challenging work because he kind of (fairly!) sees me as a black hole.

                                                                          1. 2

                                                                            Ah, okay - well, hopefully some of the suggestions in this thread can help you out! : )

                                                                            1. 1

                                                                              Haha no worries—thanks for the response. 🙂

                                                                            2. 2

                                                                              We point stories as a team, so the point value is derived from consensus.

                                                                              Does your team share an understanding of what a point means? It’s one of those things that can become quite opaque over time, and usually blends somewhere in between “complexity” (whatever that means) and “time” (what stakeholders mostly care about) and “unknownness” (which isn’t necessarily the same as complexity). Unknowns in particular can be hard to think about, but can often turn into time-sucks.

                                                                              I’m curious, are your points really derived from consensus? There are lots of social behaviours around pointing that can lead to it not being a consensus at all. Here are some I’ve encountered frequently:

                                                                              1. If points aren’t submitted blindly then people just repeat whatever is estimated by someone they either respect, or who they assume understands the issue best, or who talked first/loudest
                                                                              2. A senior figure is skeptical of higher points assigned to a ticket by the team, and talks / strong-arms the estimate down
                                                                              3. Engineers who are less familiar with the problem space of a particular ticket don’t have enough time to think/research/ask questions before pointing occurs, and underestimate their unknowns
                                                                              4. Someone wants to get the meeting over quickly and rushes the team through pointing so they can (eg) get to lunch (don’t have this meeting right before lunch, or at the end of the day!)
                                                                              5. The process for reaching “consensus” when there’s about an even split between (eg) 2 and 4 points isn’t clearly defined, and/or tends to bias the estimate to the lower figure
                                                                              6. The ticket is pointed largely based on the expertise of someone who ends up not being the one working on the ticket, and no adjustment is made
                                                                              7. Some engineers either don’t speak up, or aren’t engaged, or need to be specifically given space in order to voice their thoughts - eg, making the room quiet and asking them directly for their input, and making sure they’re not spoken over by someone else. If this doesn’t happen valuable insights can be lost.

                                                                              I’m sure there are more. In any case, these kinds of things can lead to a situation where the points assigned to the ticket don’t reflect the difficulty or time for the person who’s actually doing the work.

                                                                              And, like everyone else says, points !== value :)

                                                                          2. 3

                                                                            Honestly going into management and leadership. It forced me to become proficient at planning what I’m going to do before I do it. When I only had a minuscule amount of time to actually put my hands on the keyboard and code, I was forced to make that time really count.

                                                                            Skills that I realized as a result include spiking (researching what you’re gonna do before you do it), scoping (what’s the absolute minimum I need to change to meet requirements) and sequencing (doing A before B lets me punt on the hard decisions until I have more knowledge / realize I don’t need to make the hard decision right now). Then having to write out what I’ve shipped to non-technical folks after helped me even more in all of these areas.

                                                                            1. 3

                                                                              Late to this thread, but my 2 cents anyway.

                                                                              Data First - this single thing I believe will change your trajectory as a programmer more than any/all other things

                                                                              There is no more important thing, everything else has a shadow of the value of focusing on data. There is a lot of fantastic advice in this thread but IMHO it is all secondary or obvious once you realize data is the important thing. Your job is to transform data from one form to another – that is it. Code is a liability obviously, if you can solve the problem without code, you are in a great place.

                                                                              If you are working on something and you can’t explain the data in and the data out – you don’t understand the problem nor your role in solving it.

                                                                              • “Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” (Linus Torvald)
                                                                              • “Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.” (Fred Brooks)

                                                                              Mike Acton gave an amazing talk on Data Oriented Design in which he goes into a lot more great stuff and puts forth the three big lies (which again, are just obvious once you know your job is transforming data using a computer in the real world).

                                                                              • (Lie #1) Software is a platform
                                                                              • (Lie #2) Code should be designed around a model of the world
                                                                              • (Lie #3) Code is more important than data: “This is the biggest lie of all. Programmers have spent untold billions of man-years writing about code, how to write it faster, better, prettier, etc. and at the end of the day, it’s not that significant. Code is ephimiral and has no real intrinsic value. The algorithms certainly do, sure. But the code itself isn’t worth all this time (and shelf space! - have you seen how many books there are on UML diagrams?). The code, the performance and the features hinge on one thing - the data. Bad data equals slow and crappy application. Writing a good engine means first and formost, understanding the data.”
                                                                              1. 3

                                                                                As other suggested, number of points delivered is a terrible performance metrics. There isn’t a single metric but looking at other dimensions such as number of bugs opened against that implementation in the following months, or how easy it is for the next person to make contributions/changes to the same part of the code. It’s very subjective and impossible to quantify.

                                                                                As you original question, for me the best advice I’ve taken was to spend time learning other languages and technologies out of my comfort zone, even if it’s something I wouldn’t use professionally. Learning different languages and paradigms brings in new ideas and perspectives on how to solve problems. It open up your mind to a whole new set of approaches. It also makes you more comfortable and understanding of parts you might not necessarily interact with in a daily basis. For example, learning C will enlighten your knowledge regarding memory allocation, memory management, stack vs heap, etc which might make it a lot faster and easier for you to understand specific performance characteristics or debug an issue that got you scratching your head.

                                                                                Also, I’m not sure what the difference in experience is but experience plays a big role into performance IMO. If you’ve solved similar issues before, it’s way more likely that you’ll be able to implement a solution for something similar a lot faster than someone else who hasn’t been exposed to that class of problems.

                                                                                1. 1

                                                                                  All great advice—thank you so much.

                                                                                  Also, I’m not sure what the difference in experience is but experience plays a big role into performance IMO.

                                                                                  I think the tipping point in knowing I was becoming a problem is when people with less experience were significantly outperforming me. (I’ve been effectively plateauing for the past three years, after a promising first two).

                                                                                2. 2

                                                                                  Mostly it just takes time and experience, and unfortunately there is no substitute for those things. Don’t burn yourself out and don’t try to find shortcuts. As a number of other folks have said, writing unit tests is a way to write better code the first time, which is one way that good developers get faster.

                                                                                  Another thing someone else said that is invaluable: get enough sleep, eat reasonably well, generally take care of your physical well-being. Programming is at the level of activity where something like a headache or a nagging vitamin deficiency can notably interfere with your productivity. Take care of yourself, try to lessen the stresses in your life as much as possible.

                                                                                  And use tmux, emacs, tig… ;)

                                                                                  1. 2

                                                                                    I commit and push often even when not in a team, it’s great to have a history of what you did, branches are great nowadays with distributed vcs. That may help on metrics but that obviously is not necessary as amount of work, some commits are just fixing labels, code formatting.

                                                                                    Now to the question: What was one thing that made you a faster/better developer?

                                                                                    When I read my prior code and understood how bad it was, it did a click in my head. As an example, I had all the logic of a desktop program inside the click message handler. I was asked to add something to it, and I understood that I had to refactor it, I went ahead and did it, without feeling fear, I knew what it had to return. The result was a robust program, easier to extend and understand.

                                                                                    I started doing all in all the projects, I’m often involved in several projects/technologies at the same time, the first thing I do is to do a fresh start, install deps, database, etc. Once I know it’s running, you just need to do what you need and get the result, it’ll probably break, just keep working on it until it works.

                                                                                    1. 2

                                                                                      Writing tests in Gherkin syntax and using these to map to ‘business’ requirements, ensuring I was covering what I needed to with these tests, and making them easy + fast to run all day every day.

                                                                                      1. 2

                                                                                        I don’t think there was ever /one thing/ for me. Improving comes from introspection. Try finding your flaws, fix them. There’s various things to read. Start with Julia Evans’ recent’ post on being a senior engineer, followe the links. Maybe read the first linked article on the mature engineer.

                                                                                        Good luck on your future endeavors and P.S: if I absolutely had to recommend only one specific thing it would be communication. It’s the key to everything.

                                                                                        1. 2

                                                                                          To me, ~recently the biggest improvements in raw programming throughput recently came from two things:

                                                                                          • Prettier (I work in TS, I think there are equivalents for other languages such as Black for python)
                                                                                          • Investing some time configuring and setting up a snippet / scaffolding system that I actually use and keep up to update.

                                                                                          Also spend time exploring the plugin ecosystem of your tools. Every now and then I stumble upon some sort of extension to my IDE or browser that dramatically reduces complexity/effort for some tasks.

                                                                                          Another timeless piece of advice: know your debugger well.

                                                                                          1. 2

                                                                                            Become good at writing tests. Seriously I see so many junior engineers get stuck because they try to debug some huge blob of an application without breaking it down and testing it. Build small components & write tests. If you do that you do better than most junior engineers.

                                                                                            1. 2

                                                                                              My advice : The hardest part of doing something is thinking about it.

                                                                                              1. 2

                                                                                                Emacs and Org-mode. Learning how to track time and starting to use org-pomodoro and meticulously taking notes made me better organized and enforced strict discipline for splitting tasks to smaller sub-tasks.

                                                                                                I always knew that keeping granularity of a task to the minimum is the key to finish it faster, yet every other tool I have tried before has failed for me. Pencil and notepad is okay but my writing is so bad, that it discouraged me to ever read my notes. And searching through the notes not easy. Also I’ve tried plethora of software tools but every single one had some quirks that that annoyed me one way or another.

                                                                                                1. 2

                                                                                                  Please, no keyboard shortcuts or text editor recommendations.


                                                                                                  Well, I would have said learning to properly use the terminal. Learning Vim in the terminal catalysed that for me. If you’re in a web development shop and you’re the only person who knows how to manipulate data by composing small terminal programs together, you’ll likely run rings around your colleagues.

                                                                                                  1. 1

                                                                                                    This was the exact kind of thing I was trying to avoid. I’m obviously not a master of Emacs or bash, but getting better at them is a known unknown.

                                                                                                  2. 0

                                                                                                    There are so many…

                                                                                                    tmux - meant I could ‘pick up where I left off’ when working on the move and crappy internet connections

                                                                                                    vim - super fast and available everywhere