22 ms·

I want to inquire something that I feel only I have this problem: it takes me forever to make anything with code. Like hours to do something simple. I don't get

I want to inquire something that I feel only I have this problem: it takes me forever to make anything with code. Like hours to do something simple. I don't get distract that much, but coding is difficult and I've come to appreciate those who can code faster than me. First of all, I spend a bunch of time looking up the best way to write something. That means stackoverflow, searching for libraries, etc. Then, I would write with the debugger on. Making sure what I wrote works, one baby step at a time. I never write the whole thing in one shot like so many other programmers do. They just write pages and pages of code without ever running it, they just know its going to work (for the most part). Thoughts? How do you make progress in programming?

b4je7d7wb 4y ago
Practise. Once you are building roughly the same thing for the tenth time it will be ten times faster than the first time.
- Noumenon72 4y ago
  Perhaps I'm bad at generalizing, but after four years I feel like I am building "roughly the same thing" approximately 10% of the time. Other than SQL queries and REST endpoints, it's always mostly new technologies, new situations, and new worries. I think the personality type that reads a lot before starting the first time reads a lot before starting the tenth time, because you come back to it having learned so much and having new things you want to try. My advice for people like me is try to find a firm where you can be slow, because despite learning 1000 shortcuts you'll never be fast.
maxbond 4y ago
Don't try to write tons and tons of code at once without ever running or testing it, it's not like being a great programmer is about being so smart that you don't need to run code to see if it works. Focus on streamlining your workflow so that you can do what you're already doing more efficiently. I frequently create small experimental scripts to iterate on one aspect of a larger program, and then file that example away. I'll likely come back to it to copy code for months or years. Unit tests are your friend as well. The other thing is, read more code. Read some legendary projects in your preferred language. Read the source of your favorite framework. You don't have to read the entire codebase if you don't want, but try to understand enough of it to see where the most critical parts of the design are, and then understand how that was put together. If there are specific aspects to your programming you'd like to improve upon, and it's an area I'm knowledgeable in, I'd be happy to recommend specific resources.
- systemvoltage 4y ago
  I appreciate the advice, especially reading other people’s code. I’ve never actively done that. You know, like actually seeking a good codebase and understanding how they solved problems. Really great advice.
  - maxbond 4y ago
    Glad I could help. Best of luck!
matttb 4y ago
> Like hours to do something simple. > I spend a bunch of time looking up the best way to write something. You made it not simple
satvikpendem 4y ago
> First of all, I spend a bunch of time looking up the best way to write something. That means stackoverflow, searching for libraries, etc. This is what I do normally and it's what I was tired of. I always had to search for the "best" way of doing something, and in the end I had more "shiny object syndrome" than actually shipping anything substantial. This led me to this current project. I didn't look anything up, really. I got distracted once or twice by second guessing myself, to which I had this train of thought, as an example: "Should I use iframes or screenshots? If it's screenshots I don't want to sit there and screenshot every single site. How could I automate it? I could use Puppeteer or Playwright, let me look at their docs. [30 min later, I'd realize I wasted my time and wasn't focused on the project]. Ok, iframes it is then. I know it'll make the site slow since it has to load a bunch of data, but iframes have advantages such as showing the interactivity of a site in its dark theme that screenshots don't." And on and on. So I gave myself a time limit and just started coding. The debugger/type checker in my case was TypeScript but even still there is barely any logic to the site at all (and thus no errors), the only major part was parsing JSON (which is predictably easy in JS/TS) and for-looping through it. Next.js also has hot reloading so I can see a live preview of the page on the left side of my screen with VSCode on the right, so I wouldn't say I'm one of the coders you're talking about, but maybe those people also do something like what I do and you perhaps just thinking they're coding without ever running it.
tanin 4y ago
I have a similar encounter but with coding competitions like topcoder and codejam. I had thought I was good. For some difficult problems, I couldn't even solve it after looking at the solution.. then, there were some people solving them within 20 minutes (including reading the question and coding up the correct solution). That's when I've learned that there are people who are that good.
wruza 4y ago
This is normal to some extent for first few times when you try something new. You can reduce the devtime with the following: If it worked, generalize it a little (in a sense of factoring out constants and special cases) and add to easily-accessible snippets. You created a login form or middleware? A build config? A function that does some generic-y X? A set of useful imports? Great, save it for the next time right into your editor, right now. 99% of code is just that - modified snippets. Let this set grow unbounded and brush it up timely. Think of it as your own battle-tested SO. Making sure what I wrote works, one baby step at a time When you’re developing with logging and restart-on-save, it is a matter of ctrl-s. Sometimes it’s hard to get to the point of failure, e.g. you have to make a couple of requests (or clicks if there is ui) only to get to the point. This has to be reduced. Put a temporary “cut to the chase” code which does that. If it is a server, send these requests to yourself at the start. If it is UI, wait for some selectors to appear and click them programmatically. If it is a function, move it to tmp.<langext> and restart-on-save it there. Disable all tedious signing/cookie/role/etc checks until production. Your goal is a very hot (ctrl-s -> look -> refine) loop. It takes forever to complete and breaks cadence if it contains “blocking calls”. I seriously advise you to not use a debugger unless you’re debugging a complex algorithm or feeling a need to use it. There is no value in stepping over a mostly laminar flow, just print it. They just write pages and pages of code without ever running it Maybe they test later, or rely on a type system, or accumulate edge cases and hard to find bugs, or they mastered these parts and write from memory. Perhaps some combination of it.
- systemvoltage 4y ago
  Thanks for your take. What do you think of John Carmack's[1] suggestion that using a debugger is the best way to program? I am by no means comparing myself to Carmack :-) I find debugger a good way to "see" what the program is doing. But that leads to a lot of time wasted. [1] https://youtu.be/tzr7hRXcwkw?t=138 https://youtu.be/tzr7hRXcwkw?t=138
  - wruza 4y ago
    I think that Carmack is biased towards game development, which is different from request-response or click-action. Extensive game logs would scroll faster than framerate, rendering themselves useless (pun not intended), so stop the world and explore it is. If I had to develop a system with hundreds of parameters changing with time, depending on random() or seconds of continuous input events, then of course I’d use conditional breakpoints and live watches instead of grepping gigabytes of unstable state reports. But also, games have huds, special rendering modes (wireframe, coords, paths prediction, visibility areas to name a few), consoles, so in a sense they have some debug output that either runs at the frame rate or is just text. That said, many developers find debuggers superior to logs in any situation, and if you do so, then use it. My advice is not universal. The key point is to explore development “modes” and choose what’s suits best the “write code faster” goal in your own domain.

b4je7d7wb 4y ago

Practise. Once you are building roughly the same thing for the tenth time it will be ten times faster than the first time.

Noumenon72 4y ago
Perhaps I'm bad at generalizing, but after four years I feel like I am building "roughly the same thing" approximately 10% of the time. Other than SQL queries and REST endpoints, it's always mostly new technologies, new situations, and new worries. I think the personality type that reads a lot before starting the first time reads a lot before starting the tenth time, because you come back to it having learned so much and having new things you want to try. My advice for people like me is try to find a firm where you can be slow, because despite learning 1000 shortcuts you'll never be fast.

maxbond 4y ago

Don't try to write tons and tons of code at once without ever running or testing it, it's not like being a great programmer is about being so smart that you don't need to run code to see if it works. Focus on streamlining your workflow so that you can do what you're already doing more efficiently. I frequently create small experimental scripts to iterate on one aspect of a larger program, and then file that example away. I'll likely come back to it to copy code for months or years. Unit tests are your friend as well. The other thing is, read more code. Read some legendary projects in your preferred language. Read the source of your favorite framework. You don't have to read the entire codebase if you don't want, but try to understand enough of it to see where the most critical parts of the design are, and then understand how that was put together. If there are specific aspects to your programming you'd like to improve upon, and it's an area I'm knowledgeable in, I'd be happy to recommend specific resources.

systemvoltage 4y ago
I appreciate the advice, especially reading other people’s code. I’ve never actively done that. You know, like actually seeking a good codebase and understanding how they solved problems. Really great advice.
- maxbond 4y ago
  Glad I could help. Best of luck!

matttb 4y ago

> Like hours to do something simple. > I spend a bunch of time looking up the best way to write something. You made it not simple

satvikpendem 4y ago

> First of all, I spend a bunch of time looking up the best way to write something. That means stackoverflow, searching for libraries, etc. This is what I do normally and it's what I was tired of. I always had to search for the "best" way of doing something, and in the end I had more "shiny object syndrome" than actually shipping anything substantial. This led me to this current project. I didn't look anything up, really. I got distracted once or twice by second guessing myself, to which I had this train of thought, as an example: "Should I use iframes or screenshots? If it's screenshots I don't want to sit there and screenshot every single site. How could I automate it? I could use Puppeteer or Playwright, let me look at their docs. [30 min later, I'd realize I wasted my time and wasn't focused on the project]. Ok, iframes it is then. I know it'll make the site slow since it has to load a bunch of data, but iframes have advantages such as showing the interactivity of a site in its dark theme that screenshots don't." And on and on. So I gave myself a time limit and just started coding. The debugger/type checker in my case was TypeScript but even still there is barely any logic to the site at all (and thus no errors), the only major part was parsing JSON (which is predictably easy in JS/TS) and for-looping through it. Next.js also has hot reloading so I can see a live preview of the page on the left side of my screen with VSCode on the right, so I wouldn't say I'm one of the coders you're talking about, but maybe those people also do something like what I do and you perhaps just thinking they're coding without ever running it.

tanin 4y ago

I have a similar encounter but with coding competitions like topcoder and codejam. I had thought I was good. For some difficult problems, I couldn't even solve it after looking at the solution.. then, there were some people solving them within 20 minutes (including reading the question and coding up the correct solution). That's when I've learned that there are people who are that good.

wruza 4y ago

This is normal to some extent for first few times when you try something new. You can reduce the devtime with the following: If it worked, generalize it a little (in a sense of factoring out constants and special cases) and add to easily-accessible snippets. You created a login form or middleware? A build config? A function that does some generic-y X? A set of useful imports? Great, save it for the next time right into your editor, right now. 99% of code is just that - modified snippets. Let this set grow unbounded and brush it up timely. Think of it as your own battle-tested SO. Making sure what I wrote works, one baby step at a time When you’re developing with logging and restart-on-save, it is a matter of ctrl-s. Sometimes it’s hard to get to the point of failure, e.g. you have to make a couple of requests (or clicks if there is ui) only to get to the point. This has to be reduced. Put a temporary “cut to the chase” code which does that. If it is a server, send these requests to yourself at the start. If it is UI, wait for some selectors to appear and click them programmatically. If it is a function, move it to tmp.<langext> and restart-on-save it there. Disable all tedious signing/cookie/role/etc checks until production. Your goal is a very hot (ctrl-s -> look -> refine) loop. It takes forever to complete and breaks cadence if it contains “blocking calls”. I seriously advise you to not use a debugger unless you’re debugging a complex algorithm or feeling a need to use it. There is no value in stepping over a mostly laminar flow, just print it. They just write pages and pages of code without ever running it Maybe they test later, or rely on a type system, or accumulate edge cases and hard to find bugs, or they mastered these parts and write from memory. Perhaps some combination of it.

systemvoltage 4y ago
Thanks for your take. What do you think of John Carmack's[1] suggestion that using a debugger is the best way to program? I am by no means comparing myself to Carmack :-) I find debugger a good way to "see" what the program is doing. But that leads to a lot of time wasted. [1] https://youtu.be/tzr7hRXcwkw?t=138 https://youtu.be/tzr7hRXcwkw?t=138
- wruza 4y ago
  I think that Carmack is biased towards game development, which is different from request-response or click-action. Extensive game logs would scroll faster than framerate, rendering themselves useless (pun not intended), so stop the world and explore it is. If I had to develop a system with hundreds of parameters changing with time, depending on random() or seconds of continuous input events, then of course I’d use conditional breakpoints and live watches instead of grepping gigabytes of unstable state reports. But also, games have huds, special rendering modes (wireframe, coords, paths prediction, visibility areas to name a few), consoles, so in a sense they have some debug output that either runs at the frame rate or is just text. That said, many developers find debuggers superior to logs in any situation, and if you do so, then use it. My advice is not universal. The key point is to explore development “modes” and choose what’s suits best the “write code faster” goal in your own domain.