[-]

Ashamed_Climate_8964@reddit

The "Flow State" Bottleneck

I’ve been there. The gap between a 30-minute implementation and a 2-hour one usually isn't just about "typing speed" it's about Cognitive Load. If you have to think about where the brackets, backticks, or arrow functions are, you’re pulling focus away from the logic.

Here are three things that actually helped me:

Master the "Deftness," not just Speed: Raw WPM is a vanity metric for devs. What matters is Net Correct Keystrokes. Every time you make a typo, hit backspace, and re-type, you break your "flow state." Aiming for 100% accuracy is faster than typing 100 WPM with 5 errors.

Build Syntax Muscle Memory: 50 WPM on a standard typing test (like Monkeytype) doesn't translate to coding. You need to practice the actual syntax of your primary language—whether that’s React, Python, or Rust.

Practice with Real Code: Don't practice with "The quick brown fox." Practice with real snippets like OOP patterns or async logic.

I actually got so frustrated with this that I built codetyper.in. It’s an early-access tool specifically for developers to practice real-world code snippets.

Instead of just WPM, it gives you a "Deft score" that heavily penalizes unfixed errors. The idea is to make the "typing" part of coding so automatic that 100% of your brain can stay on the "problem-solving" part.

It also has Daily Challenges and Leaderboards if you’re the competitive type. Might be worth a shot to see if your "Deftness" is what's actually slowing you down.

[-]

Nakul0306@reddit

Here's a comment for that post:

honestly 50 wpm is prob slowing you down more than you think. when you're constantly looking for keys or hunting for brackets it breaks your flow and makes it harder to think through the logic

i'd say bump your typing speed up to like 70-80 wpm and get comfortable with symbols/syntax. typequicker has python/js practice modes that helped me a lot with typing code specifically. way different than just typing words

but also yeah learn your editor shortcuts. like if you're using vscode learn how to navigate without the mouse, multi-cursor editing, all that stuff

the speed will come from both - typing faster AND knowing your tools better. don't stress too much tho, 3 years isn't that long

[-]

RareUser1@reddit

Tbh, many of the other comments are right, but if you really want to improve your coding typing speed, I found this site called TypeQuicker.com, they specifically have a section to improve your speed on many different coding languages

[-]

Nakul0306@reddit

yo wait i actually tried http://typequicker.com/ after seeing ur comment and it lowkey works?? like i was skeptical bc ive tried keybr and monkytype before and they never rly helped w actual coding but this one has like specific stuff which is what i needed

the thing that got me hooked tho is the hand/finger breakdown thing, turns out my left pinky is absolute garbage lmao. been grinding it for like 2 weeks now and i acc notice im faster when im writing code

got my roommate into it too and now we just compare speeds whenever were procrastinating on assignments lol. hes still mad i beat his swift score

[-]

RareUser1@reddit

yeah coding speed is rarely typing speed, it’s mostly thinking + debugging. 50 wpm is totally fine.

touch typing still helps with flow though. i used typequicker.com and it has a code mode for typing practice for programmers, which helped a lot. all stats are interactive so you can create targeted exercises for any of your weak points.

[-]

sol_hsa@reddit

Better spend 2 hours writing a feature than 2 weeks debugging whatever the heck this is.

[-]

ohcrocsle@reddit

Yeah you can always improve your efficiency with your editor and typing speed, but the thing that will have your time to resolve is to get better at identifying your path to solution. You get there by slowing down and doing things right every time, and that will build your intuition for finding the right solution, and eventually you will get there when you see the problem.

Long story short, don't worry about how quickly you're working, worry about how correct your solutions are and how you can improve them. Doing it quickly comes with experience and expertise.

[-]

Crichris@reddit

More twosum

[-]

SaunaApprentice@reddit

Properly meeting requirements and being robust saves time in the long run

[-]

sierra_whiskey1@reddit

Slow is steady, steady is smooth, smooth is fast

[-]

grantrules@reddit

Rubbing is racing?

[-]

vbpoweredwindmill@reddit

Came here to say this.

[-]

grantrules@reddit

Your typing speed is really not very related to coding speed.. you're not writing an essay

[-]

NemGoesGlobal@reddit

just practice problem solving

How? What would be a proper way to practice problem solving?

[-]

grantrules@reddit

Come up with a problem and solve it lol.. it really doesn't matter what the problem is. The point is to translate requirements to code.

[-]

Robru3142@reddit

50 wpm is very good for touch typing.

Implementing a new feature is not a matter of typing speed. It’s the thinking that’s the hard part unless you’ve implemented nearly the same before.

However, iteration is important. Think of a solution (or partial) then implement it - it doesn’t have to be complete. It will be unsatisfactory- improve and try again. Repeat.

You’ll find yourself thinking in expanded ways about the problem as you iterate.

It really is an art.

[-]

Tobacco_Caramel@reddit

Your WPM aint related to programming lol

[-]

Aware-Sock123@reddit

People are delivering features in hours? 👀 I’m on a “weeks” basis.

[-]

NotMyGovernor@reddit

I remember once in my previous job I literally got docked on my yearly review once "asks too many questions". And "Is too thorough". I was like shit bro are you serious right now? You want me to just wing more shit? Sorry but damn, I don't know how to code dumb!

[-]

Aware-Sock123@reddit

Thank god that’s not where I’m at lol. The rest of my team is more like that, they’re “ticket takers”. Thankfully I immediately upon hire got lucky and was put into a role more like a feature owner vs the ticket takers, even though we all have the same title. They’re churning through tickets, meanwhile I’m completing maybe 1 per month on average. I was getting a little worried I might look bad being so different, but I recently got high praise from the project manager and CTO that I’ve been working closely with.

[-]

cyrixlord@reddit

you make time for things that are important to you. a few hours a day. reading and writing code and listening to videos on coding topics and technology and reading articles on latest trends to keep your head in the game.

its like learning spanish or any other language. it will take time.

DUOLINGO FOR NERDS

[-]

light_switchy@reddit

Think holistically about your workflow and optimize it best you can.

Are you still practicing habits that are better suited for a newer programmer? Are you spending too long correcting a certain kind of mistake? Doing too much planning, or too little? Do your coworkers interrupt you too much? Are you taking too few breaks, or too many? Are you drinking enough water? Do your choices lead you to solutions that are more or less complicated than necessary?

I don't think there's any single thing you can change to double your speed. But try to pay attention to the whole picture and find points that you can improve.

[-]

NotMyGovernor@reddit

Are you sure it's taking someone else 30 min instead of 2 hours? Simple shit can just simply take way longer than it seems. Especially when it's deliverable product.

I know half my job is fixing the shit the "speedy people" submit. I'm docked and shat on all the time "for being slow".

[-]

rbpinheiro@reddit

The mistakes I can think of that makes me take longer when implementing a feature are rushing to coding and over-engineering.

If you just go for the first thing that comes to mind and don't, at least, consider side effects and possible edge cases you will start with something that doesn't really fit the problem and you will have to come around and fix so many stuff that you will reimplement everything.

It is similar the other way around as well, when you the whole plan ahead of time and create all the interfaces and what connect with what and get super abstract before you start implementing. Chances are you will realise something you didn't before and that house of cards you built in your mind will start to fall.

Baby steps is the way to go, give yourself small goals and gather the pieces before you link them all together. This will give you the chance to re-evaluate your decisions at every step. Think of how we manage software development nowadays, we break it into sprints and constantly plan, instead of a big plan ahead with 6 months of coding before validating the idea. The fail fast principle applies to your daily coding as well.

Another aspect I think you should consider is the pressure you seem to be putting on yourself. Pretty much every developer struggles with impostor syndrome at one point or another. A clear and well slept mind makes a big difference.

Also, what type of code are those guys delivering in so little time? Watch whatever bug tracking and alerting you guys have and start doing git blames, maybe you notice other patterns other than speed.

One last tip to help you slow down and activate other parts of your brain before you start typing is to have a writing pad or a tablet by your computer so you can doodle or mindmap. It will help to organize your thoughts for when you start typing.

[-]

dnult@reddit

I loved working with Visual Studio partly because I could invent objects as I wrote the code and the VS IDE would offer options like " Create a new class Foo", and it would put the critical pieces in place with a NotImplementedException. Then I could write unit tests to pull it all together so I could develop the functional behaviors.

I spent a lot of time brainstorming doodling, and characterizing my problems in advance, before churning out a draft with a few hours of head-down development.

It helps if you're able to think abstractly about your problems, and how the logic would fundamentally work. After that think how syntax can help you get where you need to go.

[-]

The-Oldest-Dream1@reddit

Are you sure that what's slow is your typing speed and not your problem solving? It's usually the case that a person's problem solving skills are slow

It's best to work on your problem solving instead of improving your typing speed. If you still think that your weakpoint is your typing speed then there are plenty of good tutorials on YouTube

[-]

dashkb@reddit

I was regarded as fast… competency with your editor is important as you don’t want it to get in the way of your thoughts. That said… I had extra time to make my editor awesome because I was already “fast” with TextMate or whatever.

Analyze how you spend your time. What takes the longest? Actually inputting the code? Probably not. Figuring out how to solve the problem? Maybe. Debugging and testing? Probably. Figure out where you’re struggling and target improvement there.

If you can’t figure out what’s slowing you down, that’s your problem right there. Sorry if that comes across snippy… I’m just telling you to debut and performance profile yourself as if you were a program.

[-]

Sophiiebabes@reddit

Something I've done before and am totally familiar with might take me half an hour or an hour, but if it's something new it's easily going to be a few hours by the time I've figured it out. Don't stress.

[-]

mxldevs@reddit

Programming speed is based on how fast you can come up with a solution, how much of it you can plan out, and how fast you can implement the design.

Most people slow down when they don't have a plan and they're trying to figure out what to do on the spot. Then they find out they can refactor something, but if they had thought it out beforehand they would likely have refactored it before even hitting the code.

[-]

effortissues@reddit

You shouldn't be trying to rush when coding, that only increases the number of potential errors. Take your time, do it right and your co-workers will appreciate you. Unless you're failing to meet SLAs, that's a whole different problem.

[-]

ToThePillory@reddit

It just takes time, and it's not a very useful measure to think along the lines of "he took 1 hour, I took 2 hours" to do something. Real programming progress is measured in months and years, thinking in hours is like timing a road trip and including how long it took you to put on your seatbelt.

Typing speed is unrelated to programming speed.

It's just about getting better.

Write real projects.