5 ms·

funny how people pay attention to how fast it is to change a piece of text in a editor. Most of my time programming is spent on a piece of paper or a whiteboard

by bsaul 12y ago

funny how people pay attention to how fast it is to change a piece of text in a editor. Most of my time programming is spent on a piece of paper or a whiteboard designing my data structures and algorithms. Actual typing , especially with an ide providing auto completion, is the thing that takes me the least amount of time, by far.

toxik 12y ago
I don't believe that to be true, and I have never met a developer who thought that to be true. Sketches and diagrams can design a large system, but at the end of the day, unless you're a systems architect or something, you're going to have to get your hands dirty.
- edejong 12y ago
  The best and lowest-maintenance pieces of code our team has written were carefully designed and thought out before a line of code was written. I'd say 20% of the actual work was coding, 30%/30% for design and testing and 10%/10% for requirements analysis and deployment. However, often we know that we don't know how to properly design something and we start implementing too early. The end result is sth like: 50% coding, 30% testing and the rest is squeezed into testing, deployment and requirements analysis.
  - bsaul 12y ago
    Starting on a paper instead of coding directly is really the key to the best quality software i've done. Funilly i realized that very early at university, where i had to perform a code exercice while on holidays, but forgot to take my computer with my me. I did it on paper, then typed it when coming back home, and got the best grade.
nothrabannosir 12y ago
Even if that is true, we remain human and annoyance is not typically subject to reason. When I'm typing in Visual Studio and I find myself spending a second moving the cursor from the top of the screen to the middle, it's a second that breaks my train of thought. Ugh, now I'm thinking about this editor. Instead of typing M and continuing with what I was doing. I can imagine it to be a little like holding a speech with a stutter. Sure, most of your time is spent on prep. That doesn't make the pauses less annoying when you're actually talking. But I don't stutter, so maybe that's ridiculous.
agumonkey 12y ago
I cringe every time people are amazed by ad-hoc text processing in an editor thinking it's nice programming.
mattmanser 12y ago
I never sketch anything out and designing data structures is done in the editor. Why are you spending such a vast amount of time on something so simple as data structures? Seriously. It's pretty much a solved problem these days. You should have read enough of other peoples code to see the common patterns, especially in your industry. I'm serious that if you spend a lot more time on white boards and paper than programming in this day and age, there's something wrong.
- bsaul 12y ago
  Every original algorithm ( or even an original GUI component) has its pending original data structure. Designing an algorithm most often starts by identifying its parts and most adapted storage&query structure. I suppose you're just writing boilerplate code, assembling pre coded components within the boundaries of a framework... That's the kind of boring job i usually try to let interns or beginners do, mostly because it's not economically interesting for customers to have that kind of job performed by senior devs/architect ( it does take more time than brain).
  - mattmanser 12y ago
    Yeah, that's exactly what I'm doing. Or not. We're way past the decades where you had to sit around "thinking" for ages to come up with a data structure. You still loading the program up on cards or something? You saying it is as preposterous as the guy I met a couple of years back who offered to come and design SQL DBs for me. It's just not done any more. That's not how we work any more, that time has past. In today's world you can prototype up the basics of any complex system in an hour or two and throw it away if it doesn't work. Tests are cheap, it's easy to mock, there's no compilation to worry about. And if you can't look at a problem and immediately see the effective ways you've solved similar problems before, well, you're not as senior dev/architect as you think you are. You simply sound dated to me.
    - bsaul 12y ago
      It is indeed a very dated method, but you should try it once. You'll see that by thinking first, coding later, you'll gain a lot of time overall ( you're not always able to see with your code that something doesn't work). Now of course you don't need this method for trivial things, but i hope that's not what you spend most of your time working on. Note: i didn't downvote you.
brianpan 12y ago
The measure of a tool should be: how much of an improvement is it over not using it. It's not about how fast a bike can go, it's how much faster it is than walking. vi can be a huge speedup doing text manipulation. Programming is not just manipulating test, but manipulating code. An IDE helps me with syntax, completion, extracting/inlining, modifying signatures, refactoring, etc. A corollary is: if you're making a tool, make sure it's leaps better than the simplest alternative. I have a friend who gauges lasagna at a restaurant against Stouffer's frozen lasagna. Because Stouffer's is delicious and if I'm going to a restaurant and paying a lot, it has to at least be better than something I can easily heat up at home!
- bsaul 12y ago
  I see it a bit differently : why spend time learning a weird way of updating text in a file when that activity isn't the most time consuming one by far ( and there are many more important other things to learn).

by bsaul 12y ago

toxik 12y ago

I don't believe that to be true, and I have never met a developer who thought that to be true. Sketches and diagrams can design a large system, but at the end of the day, unless you're a systems architect or something, you're going to have to get your hands dirty.

edejong 12y ago
The best and lowest-maintenance pieces of code our team has written were carefully designed and thought out before a line of code was written. I'd say 20% of the actual work was coding, 30%/30% for design and testing and 10%/10% for requirements analysis and deployment. However, often we know that we don't know how to properly design something and we start implementing too early. The end result is sth like: 50% coding, 30% testing and the rest is squeezed into testing, deployment and requirements analysis.
- bsaul 12y ago
  Starting on a paper instead of coding directly is really the key to the best quality software i've done. Funilly i realized that very early at university, where i had to perform a code exercice while on holidays, but forgot to take my computer with my me. I did it on paper, then typed it when coming back home, and got the best grade.

nothrabannosir 12y ago

Even if that is true, we remain human and annoyance is not typically subject to reason. When I'm typing in Visual Studio and I find myself spending a second moving the cursor from the top of the screen to the middle, it's a second that breaks my train of thought. Ugh, now I'm thinking about this editor. Instead of typing M and continuing with what I was doing. I can imagine it to be a little like holding a speech with a stutter. Sure, most of your time is spent on prep. That doesn't make the pauses less annoying when you're actually talking. But I don't stutter, so maybe that's ridiculous.

agumonkey 12y ago

I cringe every time people are amazed by ad-hoc text processing in an editor thinking it's nice programming.

mattmanser 12y ago

I never sketch anything out and designing data structures is done in the editor. Why are you spending such a vast amount of time on something so simple as data structures? Seriously. It's pretty much a solved problem these days. You should have read enough of other peoples code to see the common patterns, especially in your industry. I'm serious that if you spend a lot more time on white boards and paper than programming in this day and age, there's something wrong.

bsaul 12y ago
Every original algorithm ( or even an original GUI component) has its pending original data structure. Designing an algorithm most often starts by identifying its parts and most adapted storage&query structure. I suppose you're just writing boilerplate code, assembling pre coded components within the boundaries of a framework... That's the kind of boring job i usually try to let interns or beginners do, mostly because it's not economically interesting for customers to have that kind of job performed by senior devs/architect ( it does take more time than brain).
- mattmanser 12y ago
  Yeah, that's exactly what I'm doing. Or not. We're way past the decades where you had to sit around "thinking" for ages to come up with a data structure. You still loading the program up on cards or something? You saying it is as preposterous as the guy I met a couple of years back who offered to come and design SQL DBs for me. It's just not done any more. That's not how we work any more, that time has past. In today's world you can prototype up the basics of any complex system in an hour or two and throw it away if it doesn't work. Tests are cheap, it's easy to mock, there's no compilation to worry about. And if you can't look at a problem and immediately see the effective ways you've solved similar problems before, well, you're not as senior dev/architect as you think you are. You simply sound dated to me.
  - bsaul 12y ago
    It is indeed a very dated method, but you should try it once. You'll see that by thinking first, coding later, you'll gain a lot of time overall ( you're not always able to see with your code that something doesn't work). Now of course you don't need this method for trivial things, but i hope that's not what you spend most of your time working on. Note: i didn't downvote you.

brianpan 12y ago

The measure of a tool should be: how much of an improvement is it over not using it. It's not about how fast a bike can go, it's how much faster it is than walking. vi can be a huge speedup doing text manipulation. Programming is not just manipulating test, but manipulating code. An IDE helps me with syntax, completion, extracting/inlining, modifying signatures, refactoring, etc. A corollary is: if you're making a tool, make sure it's leaps better than the simplest alternative. I have a friend who gauges lasagna at a restaurant against Stouffer's frozen lasagna. Because Stouffer's is delicious and if I'm going to a restaurant and paying a lot, it has to at least be better than something I can easily heat up at home!

bsaul 12y ago
I see it a bit differently : why spend time learning a weird way of updating text in a file when that activity isn't the most time consuming one by far ( and there are many more important other things to learn).