5 ms·
Very fast. Let me explain. I work in 2 modes: (A) At the computer and (B) Away from the computer. When I'm in Mode A at the computer, I'm cranking out lines
by edw519 16y ago
Very fast. Let me explain.
I work in 2 modes: (A) At the computer and (B) Away from the computer.
When I'm in Mode A at the computer, I'm cranking out lines of code, testing, revising, testing, revising, etc. This process must be very fast. Several hundred lines of code (or whatever) in less than an hour. A complete cycle in less than a couple of hours. My guideline is that if I'm not working that fast, then I must not be prepared to work that fast, so I don't deserve to be at the computer. I should be in mode (B).
Mode B is generally much slower. Reviewing code, specs, or notes. Refactoring code. Laying things out with pen and paper. When I have enough work clearly laid out, I know it's time to get back to the computer and return to Mode A.
The most important thing for me in Mode A is to see results, any results, quickly and often. It doesn't matter how correct anything is, just as long as it's progress (or sometimes, reverse progress). I like to think of programming as making incremental progress in micro jumps, evaluate where I'm at, and go for the next micro jump.
Some of the best advice I ever got was from a prolific artist friend of mine who claimed, "I paint every day." So I started coding every day. But that wasn't enough. Now I make progress every day.
There are many definitions of progress. Sometimes I copy a few hundred lines of code, make a few changes, spit out a new app, and then start applying micro changes. Other times I decide that I need to see <x> today and find a way to get there. Things don't always work out as planned, but that's OK. As long as tomorrow's starting point is beyond today's, I'm satisfied.
That's my definition of fast. Not sure that was what you were asking, but I hope that paints you an accurate picture.
- olliesaunders 16y agoWhat language do you use?
- edw519 16y agoBASIC, php, and javascript
- makeramen 16y agowoah, where are you using BASIC? excuse the naivety but I’m not sure I’ve heard anyone use that professionaly in... ever.
- donw 16y agoI don't knw what edw does, but there are a lot of small businesses that need small one-off desktop apps, for which VB is perfect.
- logic 16y agoAgreed here; I've seen that a lot with in-house stuff. At my wife's former employer, almost all of the internally-developed stuff that she supported was a mashup of VB, Access, PowerShell, and third-party tools that they glued together.
- ramchip 16y agoI could understand this, but I've never heard of the all-capital BASIC referring to Visual Basic.
- jpr 16y agoModern VB is certainly good for that. But calling it BASIC is like calling Common Lisp LISP.
- axod 16y agoThe 'b' still stands for "beginners" whatever you call it.
- mkramlich 16y agoassuming you're serious.... why that mix? why BASIC today in a world where Python exists, Java, Ruby, Lisps, C, etc.?
- mmaunder 16y agoedw is obviously a smart guy and I too have not heard of BASIC used in production or for anything recently for that matter, so I find myself very curious and would love to know more about how you're using it. I'm a Perl developer btw and many here consider that on a par with BASIC and might ask the same question of me.
- shasta 16y agoThis is pretty much the system that I use, but (B) is often at the computer, e.g. open to a text file that contains design notes.
- viraptor 16y agoWhat kind of code / environment do you mean? Are you writing to a spec, or design from scratch? To be honest, I've never seen anyone working this way, meaning - I've never seen anyone able to design something away from keyboard that doesn't change significantly once it's written (unless they have a strict interface to fill, or something similar). Also, do you actually write out pseudo code on paper (regarding "reviewing code", "Refactoring code")?
- edw519 16y agoI've never seen anyone able to design something away from keyboard that doesn't change significantly once it's written It does change once it's written. The idea is to get a clear work plan on a "close enough" design. I estimate that my first cut of anything is maybe 50% or so. The idea is also to avoid sitting at the computer all day and then being disappointed with how little I accomplished. Activity != accomplishment. A little more background... First term freshman year, 90% of science students took Chemistry I. On Mondays and Wednesdays, only 50% of the seats in the dining room were taken for dinner. Chem Lab started at 1:00 p.m. and dinner was at 6:00 p.m. So, most freshman chemistry students took more than 5 hours to complete their lab work. This never made sense to me. I took Chemistry I second term freshman year. My lab partner and I made a pact to never miss dinner. We did everything we possibility could to expedite lab time. We did all the reading, planning, and reviewing other people's results before we entered the lab. We even wrote our reports in advance, filling in the results as we went. Our longest lab took 2 1/2 hours. Our shortest took 1 1/4 hour. (We also both got A+.) I still practice that methodology today. My computer is my lab and my bed or sofa is my lab prep. Preparation takes as long as it needs. Labs go fast. If they don't it's because I wasn't prepared enough when I started.
- benatkin 16y agoThis, and your earlier comment, are great food for thought! I'm trying to overcome distractions when I get stuck coding, and have been trying to establish a habit switching to paper at that point. The problem is, when I'm at that point, I'm usually frustrated and find it hard to fend off the urge to check out Boing Boing or HN. Having things planned out on paper beforehand could help me avoid reaching that point in the first place. Also, thanks for posting some highlights of your activity on HN to your blog. I looked at the archives and found more good content there. I certainly think the points you made in this thread are worthy of being featured there.
- invertedlambda 16y ago'Some of the best advice I ever got was from a prolific artist friend of mine who claimed, "I paint every day." So I started coding every day. But that wasn't enough. Now I make progress every day.' Agree. While he's not everyone's favorite, I enjoy Stephen King's books very much. His recipe for success? King's formula for learning to write well is: "Read and write four to six hours a day. If you cannot find the time for that, you can't expect to become a good writer." He sets out each day with a quota of 2000 words and will not stop writing until it is met. He also has a simple definition for talent in writing: "If you wrote something for which someone sent you a check, if you cashed the check and it didn't bounce, and if you then paid the light bill with the money, I consider you talented." (http://en.wikipedia.org/wiki/Stephen_King#Writing_style http://en.wikipedia.org/wiki/Stephen_King#Writing_style) Notice how he says both reading and writing are keys to success. :)
- mishmash 16y agoLove that quote and this one too, from your link: "He is also often asked why he writes such terrifying stories and he answers with another question "Why do you assume I have a choice?"" Many of us probably feel the same way about programming. :)
- bugsy 16y agoYou write several hundred lines of code per hour? Excluding comments, no doubt. What language?
- mkramlich 16y agoI've done that many times. It's not hard if you're "in the zone": you know exactly what you want to do and how, the language nuances and the application structure/state are all fresh in your mind, no interruptions, etc.
- ramchip 16y agoI'm sure it's quite language- and project-dependent though. Considering xmonad weighs 1200 LOCS, at this speed you could write a full-fledged window manager in a few hours.
- bugsy 16y agoWhen you say you also write several hundred lines of code an hour, how many hundreds of lines do you mean by several? 200? 300? 600? 900? Are you including white space? Are you including comments? What language are you coding in?
- melling 16y agoTry working out the amount of code you write in an average day, or week. If you're writing, say 500 lines per hour, for 4 hours a day. At 5 days a week for 50 weeks, you've written 500,000 lines of code in one year.
- IgorPartola 16y agoI do something similar. I actually often spell out code that I want to write while away from a computer. To me it also feels wrong to go through what you call mode A and not have the project working (unless it is in really early stages). So I get the basic structure set up, refactoring 3-10 times in the process, then write a list of features. Each time I get to code I knock put at least one feature and commit to the VC repo. Of course sometimes I add new features so the list gets longer. I know I am wrapping things up when it starts getting shorter (knocking out more features than inventing new ones). It doesn't always work so I end up leaving the code base without the feature completed. If this happens I end up being obsessed with the unfinished feature to the point where I spell out code in my sleep. Good to see that someone else is using this pattern.