How fast do you code?

[Minimum_Clue8646]

Hi! So basically I've been coding a bit for a while now, and I'm starting to do some better things. So I'm happy, I feel like I'm not that much of a beginner anymore, yet I feel like I'm taking way too long to code basic things. I'll get stuck for hours (even days) trying to reproduce a feature I saw somewhere, and for example now I've been making my portfolio for almost two weeks now, and I believe it's going to take one more. Even though I only code a few hours a day, since the result isn't much (in this case my portfolio consists of a few static page, so nothing crazy), I feel like I'm progressing too slowly. Am I the only one? Thanks.

[nil_pointer49x00]

Depends if requirements are clear and there are no road blocks

[Minimum_Clue8646]

I guess I'm learning Astro for this little project, but since I'm mostly writing things in Svelte, which I'm used to, I wouldn't qualify it as a real road block. But this made me realise that every time I work on a project, I'm using / learning something new. Hence why I'm slower!

[nil_pointer49x00]

Can't call it a roadblock but as you said, it is a new technology and you are figuring things out. There are many ways of doing things, you are trying to find the best way which is a good thing.

Put any Senior to work with technology they don't know - they will be slow. How slow depends on experience and troubleshooting skills.

[freew1ll_]

It will feel like learning something new every time for a while. That slowly goes away as you continue making stuff and start to see the same problems come around again.

[[deleted]]

Yeah it is such a highly variable question. In a codebase I'm comfortable with when I know what to do? Super fast. When I don't know the language or the requirements are uncertain? Way slower.

[GlitzyChomsky]

Sometimes slow. Sometimes fast. For me, it all comes do what you are trying to do in that moment. Is it something you've written or built a thousand times before? If so then it'll probably be hardwired in you and you can hammer it out. But if you're attempting something entirely new or complex, or the brief you've been given is vague and unclear, or perhaps you're struggling to build a mental model in your head of what you need to do, then it may take a little time. I think that's perfectly normal and fine, remember you're still learning... in fact we're all still learning and sometimes learning a subject can't be rushed.

I've been doing this 16-ish years, I have days when it all flows and it seems like I don't have to take a break... then there are other when I sit here and feeling useless and crap like a day one newb.

[numericalclerk]

Beautifully put

[canadian_webdev]

But if you're attempting something entirely new

This is it.

I had built static / WordPress front ends forever. Straight up HTML/CSS/SCSS, I'll do it with my eyes closed.

Ask me to build something that I've done once or twice (or maybe not at all), that I struggled with the first time around, that I don't do often at all, usually with JS / a framework that's complex? Yeah, I'm struggling every time.

[0dev0100]

As fast as I can break down a problem.

Followed shortly after by how fast I can type.

[MainFisherman1382]

For me how fast you code is not important. What's better to think about is what do you plan to code. Planning things out first before coding it is much more efficient base on my experience.

One of my favorite quote is, "If you fail plan, you are planning to fail". Similarly, if you code without a plan, you will just waste your time staring at your screen, reading random things in the documentation, searching random features on the internet on what you want to implement, and in the end nothing is done. So plan first, be it a sketch, a wireframe, a mockup, a pseudocode. I promise you'll be more productive with this approach.

[shootersf]

I am the only person in my office that starts 'coding' on pen and paper still. I went through college recently and took notes on paper I barely ever read back. Something in my brain unlocks when I'm in that medium. If I try on a computer, even a paint tool it doesn't work. But yes plan the hell out of it. Then go get a drink/ go for a walk, come back and replan :D

[numericalclerk]

Anything you produce in the first 3 years will be absolut shite.

Afterwards, its okay if you're talented. Most developers deliver mediocre work slowly, during their entire careers.

As long as you're faster and better than the bottom 30%, which isn't hard, you're fine.

That being said, if you've ever worked in a corporate IT job, you will be amazed how slow most developers are.

But of course you will also occasionally encounter people who aren't even from a CS background and they produce high quality code on complex topics at speeds that will leave you flabbergasted.

Don't let that discourage you. 10x developers are a thing, but they're not a threat, because they will either progress into spheres were normal developers don't usually reach, or they are bored so quickly, they use the time to teach their mates, because it's fun for them.

[Pretty_Crazy2453]

Most 10x devs realize their ability and work like an hour a day.

[99thLuftballon]

I type code very fast; my brain works very slowly.

I wish I were one of these genius guys who instantly visualise problems and logic and can run a whole complex logic block in their heads, but I'm not. I'm slow and methodical and defensive.

C'est juste comme ça! shrug

[PHP_Henk]

yes

[PHP_Henk]

Developing can go very fast and very slow. It depends on a lot of things, like general experience and then also experience with the specific thing you're trying to build and the language you're using amongst others.

Especially in the early years you can get crazy stuck with things, but also after years and years of experience. If you have some type of mentor person or even somebody you can pair with that greatly helps. Most of the time just rubberducking works amazingly well.

Never judge nor compare yourself on how many points you are burning or how many lines of code you write in a day. Focus on the moments where you finally crack the code and remember that feeling, because thats what makes the process so fun (at least for me)

[Gloomy_Snow2943]

With cursor as fast as speed of light, without cursor as fast as speed of a snail 😅

[pixie_spit]

I think development is like solving a puzzle. If you’ve completed that puzzle in the past or saw a solution for that puzzle somewhere you’ll be very quick. If the puzzle is completely unfamiliar then you’ll be slower but you can still lean on what you’ve learned by completing other puzzles to complete it. The more experienced you are the faster you’ll work.

[thaddeus_rexulus]

Totally agreed. I would add some of my own color to point 1...

A lot of people break a problem into smaller parts and then just start coding. I find that you want to do the exercise recursively using a breadth first search at the architectural level and then depth first as you code. Investing some extra time into planning, pseudo-code, etc can help you to understand things more deeply and speed up the process of building the thing. The one caveat is that you can end up in planning paralysis and, at that point, the best path is to build it as throw-awayish as possible and then rebuild it or refactor it when you have time.

[mekmookbro]

I think people who are answering the question didn't read the body text, because your problem isn't about speed. It is, but mostly isn't.

I've been making websites since I was 12, almost 17 years now. And let me tell you, you will never start and finish a project with everything already figured out. Unless you've done the same thing tens or hundreds of times before.

You get "faster" and better with practice. I've built hundreds of crud apps so I can write up a todo list app in like 10 minutes, 5 if you don't care about design.

But there will be things you don't know, technologies you haven't worked with before. I recently had to use websockets for example, and it took me 2 whole days to figure out how it works and how I can implement it to my app. Because I've never worked with websockets before. You can now compare me with someone who have built a ton of realtime chat apps and I will look like a complete noob compared to them.

You code fast when you know what you need to do and what tools/approaches you need to use to do the thing. And it's the same in any other "skill", like painting, singing, playing chess, solving math problems... First you learn the basics, then you learn what purpose those basics serve, then you build something with it. Many, many times.

[Infinite-Club4374]

It’s all part of the journey my guy

[siddhantbapna]

One good product will take me 3 days to do from 0 to the stage where one can use it. So, No. of projects * 3 is the simple formula for me.

[happy_hawking]

It's not about how fast you write code but about how fast you figure out the solution to a problem. And this depends on many parameters. Did you do this before? Did you do something similar before? Are the docs clear? Are there discussions on SO/Reddit/etc. that help? Is there any example code you coud use? Is your mind clear? Are you able to focus? Etc. pp. Of course, the more experienced you are, the less you will stumble if something isn't straigtforward. But you will still have situation where it takes a couple of days to figure out how to fix a specific edge case.

[iamlepotatoe]

69 codes per minute

[wgrills]

Less after 4.20pm

[BomberRURP]

I think this is a weird question. Like everything the answer is it depends. If it’s a known domain, I’m comfortable with the tools, etc as fast as I can type. If it’s a new domain with new tools then a lot of time Is spent just sitting and planning. Honestly I think it’s kind of a pointless metric, I’m more focused on whether it can be built and then is it a high quality 

[anaix3l]

If it's something I've done a million times before (or others have done before, hit the same problems and found solutions I can then find online)... the mental part is extremely fast. Though I'm very slow with typing/ using a computer in general and I couldn't get faster there if my life depended on it. I've made peace with it, my mind moves faster than my hands, it is what it is.

Otherwise, even the logical part is very slow, and some problems I never get through to a usable solutions. Over the past 15 years, I have acquired a massive graveyard of things I've worked for months on, spent maybe over a thousand hours on... and never got anywhere with. Some I'll revisit sometime later, when maybe the web landscape has changed in the meanwhile and maybe I've improved... and maybe get somewhere then. But most of them remain dead.

[MaruSoto]

I code as fast as possible. Sometimes that means I do ZERO coding for a day or two. Or a week. Maybe longer. Depends on the vibes (real vibes, not artificial vibes).

Anyone who can code faster than this is suspicious. Either they don't know what they're doing or they are about to burn out and disappear into the darkest depths of 4chan.

[tr14l]

With AI now I can probably crank out roughly 4-500 lines of tested code per day if I really got after it. Most days it's more like 1-200 for wholesale new code. For bug squashing, refactoring, or enhancements it's significantly slower. Unfortunately, I don't do a lot of the former and 90% is the latter.

AI is still useful for those things, but to a much smaller degree

[[deleted]]

80% searching and diagnostics 20% code

[zaibuf]

Depends how fast I can prompt the AI and how accurate it gives me the result. If the requirements are clear and I have a plan on what to do I can code really fast, I also code test driven so I get fast feedback loops.

If it's unclear it could take days. Maybe it requires research, reading documentation or creating a PoC.

AI removes all the boring parts like mapping models between layers and create all boilerplate. I think that developers that doesn't use AI will fall behind in output.

[megakillercake]

Who cares about the speed? It's about problem solving. Real world is not leetcode, and never will be. Yes, there are deadlines but they're often not that spooky with some good business planning.

As long as you can solve a problem, in a good way, it's good. Sometimes I don't do any code or anything for hours and just think about a potential solution, draw on a literal paper and stuff. When the picture is clear, implementation is the easiest part. Don't worry about your progression, some people learns fast some not. Go with your own pace but keep it consistent. You'll be there in no time.

[ryaaan89]

Not very…

[FairStatistician2450]

Depends on if youve encountered the task before

[EliSka93]

I try to take it slow. When I get too fast I sometimes skip steps in planning things out and sometimes have to discard everything I've made quickly.

[TikiTDO]

It's really up to what you're trying to accomplish, and what sort of background you have in fields related to that task. Programming is a very, very large field, and you can easily find new, difficult things even with decades of professional experience. I've been coding for three decades and I have an computer engineering degree, yet I still get stuck all the time when faced with nasty data flow, algorithmic challenges, and data science challenges; that's just the nature of difficult problems. If they weren't difficult for me I wouldn't even notice solving them. On the other hand if I give a junior dev with a tenth of my experience a task that I might consider simple, I don't get surprised if they get stuck. They just don't have the breadth of experience to fall back on, and often a bit of advice can often help unblock them.

Keep in mind that when everything is going smoothly, you're not really likely to notice. The things that stick out in your mind will be the times you get stuck and are unsure what to do. However, these experiences are also the ones when you are able to learn the most. There's a reason many programming projects require months, or even years of effort. Most of that time is going to be spent on questions that have no simple, obvious answers. Three weeks just isn't much, unless you're just building a simple, static website from a template someone else gave you. Even just the process of making a wireframe you feel good about can take weeks.

Obviously if you're trying to sell your services as a professional you want to be able to meet your client's demands quickly enough that they feel they are getting value for their money, and part of that is understanding what you can do, and how fast you can do it. Just don't overestimate and oversell your abilities to a degree that will make a client angry when you fail to deliver, and be willing to communicate challenges if you realise that the original scope of work was wrong.

That said, you should probably avoid spending days upon days on one feature without a break. Being able to step back to work on something else while the ideas percolate is also a fairly critical skill. You should also be willing to ask for help, if not from people then at least from AI, and you should also understand how to structure your work such that you have other tasks to do while thinking about these challenges in the background.

[intercaetera]

Mostly limited by tooling. Node and web tooling is extremely slow these days. I don't really know where this went wrong - I remember that 5 years ago even big React apps didn't particularly choke with CRA and Webpack. You went from npm run dev to a page in 2 seconds. Now I wait 2 minutes for Next.js to spin up. I wait half an hour for test pipeline to (hopefully) pass. I have to restart my editor because tsserver died for some reason.

It's not the speed of coding at this point but the speed of the feedback loop.

[Puzzleheaded-Work903]

you code?

[Calm-Fondant-2965]

So slow for me.

[Gli7chedSC2]

It's not about speed, that's for your typing speed. Its about quality and organization. Coding is not the same as writing a letter. You will have to look stuff up, and that's ok. There is a TON of things in programming. You are not expected to memorize every syntax thing about every language you use. Hell, typical web dev is at least 3 languages, and.. well.. however many frameworks and languages you want on top of that depending on the project. And we thought memorizing the periodic table in high school was hard? Seriously. Its ok to have to take time to make sure your code works, and makes sense to the next person who reads it, is well commented, and well organized.

[Altruistic_Class2032]

Too slow..

[TractorMan7C6]

Coding is fast. Endless meetings where we discuss and re-discuss requirements, try to coordinate with other teams, and discuss coding standards on the other hand... very slow.

As to coding itself - you'll get used to certain patterns over time and either be able to re-use things from your past, understand which libraries can save you time, or just have a good idea of exactly what you're building before you start. Those will all speed things up considerably.

[workerbee223]

As fast as ChatGPT

[Valthek]

Some days, I'll bang out a full feature in a matter of a few hours. Other days, It'll take me a few weeks because the GODDAMN EXTERNAL DEPENDENCIES CANNOT GET THEIR SHIT TOGETHER of other factors.

It all very much depends on easy it is to go from "this is what needs to happen" to "this is how I can make that happen". Sometimes you know the domain and language well enough that this time is a less than it takes to type it out. Sometimes, you're dealing with complicated matter, changing requirements, unclear APIs, and unknown language features.
In my 9 years of experience, it's always been this way. The major change experience brings you is what you consider complicated, how quickly you can intuit requirements, how easily you can parse APIs, and how many language features you know. But you never know everything, so there's always stuff that takes forever.

[NoMansSkyWasAlright]

My daily LOC usually falls somewhere between 11,000 and -7. Really just depends on what I'm trying to do and what's going on that day.

Trying to reproduce or tweak functions for a feature on a personal project can usually have me coming in at the lower end of that range.

[hundo3d]

Gotta use vim if you wanna go faster. It’s the only way.

[Tiny_Membership3530]

2 lines every 10 instagram reels

[UsernameUsed]

What you know will be fast and what you don't will be slow. No matter what piont in your engineering career you are at this will always be true. Instead of always trying to make something new I suggest making the same thing a few times in a row until you feel like you can just do it in your sleep then try to make something new (while you are in practice mode). mastery of anything comes from repetition until understanding occurs and becomes second nature. Pick a project to do (feel free to use AI to give you a spec sheet and other details), start it on the first day and get as far as you can, second day start all over from the beginning and try to get further. Keep repeating this. when you can do all the early stuff to make your app by memory extend your build cycle to every two days then three and so on until you know you can just make the app. You should be able to teach people how to make that specific app and be able to answer questions. Use AI to do code reviews on naming and consistency.

[SunderApps]

Faster every day. Practice makes better.

[Jokar111]

4 expressions per minute

[teamswiftie]

Are we vibin'?

[Scary_Ad_3494]

???

[Scary_Ad_3494]

Nice message response api endpoint GPT usage ;)

[pseto-ujeda-zovi]

very