Good commonsense stuff.
> Think hard about the problem for a few weeks before typing any code.
In my case, it's never more than overnight, but maybe it's because I am working on a smaller scope than the author.
> Think hard about the problem for a few weeks before typing any code.
In my case, it's never more than overnight, but maybe it's because I am working on a smaller scope than the author.
Reaching high performance means knowing the solution before coding it up.
Witnessing high level competitive programmers scribble stuff on paper for 5-10 minutes, and then just a pure stream of thought into a 100 line C++ program that was compiled once, run through examples, submitted and accepted, is out of this world.
Another example is when solution is unclear (mostly for number theoretic stuff that needs to be efficient), scribble on paper, code up pattern generating code, generate patterns, look at them, stop, scribble on paper, code the O(1) solution, submitted and accepted (an easy example is to efficiently calculate the sum of first N Fibonacci numbers).
I'm not competitive, anyway. It's really a life choice, and a moral stance.
Also, that's not how my brain works.
I'm not really interested in proving myself to anyone, or beating anyone else.
I just enjoy writing good stuff that people use.
I'm always humbled when I try to solve something, need 50-100 lines of code, and then there's a solution that really gets what the inputs/outputs/intermediate data structures are and it turns out to be just 10 lines of code (written during live competition, I'm amazed by the truly simple thinking of these authors). The best problems that demonstrate that are most often just algorithms with arrays (no specific algorithm, only required knowledge is working with arrays). True display of thinking things through before coding.
I guess example that come to mind (a mindblowingly simple algorith, try to find it yourself): https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_majority_v...
It gives me similar feeling (but less pronounced) to looking at tinycc, or looking at some tree enumeration algorithm in TAOCP, or the modification of it done by Knuth to support enumerating arithmetic expressions without redundant parentheses (also just an array algorithm, figure out how to modify an array that represents existing expression into an array that represents next expression, literally just a bunch of loops).
I had to handle time series data at work. There already exists 1000s of lines of code that deal with time series, sorted timestamp arrays, {up,down}sampling, timezone handling etc. All of that can be replaced by a simple 5 line function that works faster (supports tz, sampling, appends etc.). Only possible to write if you really focus on the problem you're solving and realize that the sub-problem you envisioned (the "efficient" time series data structure) does not really help you.
You’d be surprised how experience can shorten the planning time.
Also, I’m not quite “neurotypical,” and avoid writing things down. I tend to keep my strategic model in my head. I’m constantly wargaming my strategy. You might be surprised at the scope of the project I’m doing right now. I’ve been working on it for around two years, and we’re getting within sight of the finish line. About the only time I write stuff down, is when I want to pass it by other team members.
I’ve also learned that, sometimes, there’s no substitute for writing some code, stepping through it, and seeing how that jives with your strategy.
To do things my way, you have to be willing to toss out a lot of code; sometimes, weeks’ worth of code.
If you wasted weeks coding the wrong thing then you didn't solve it overnight. Making mistakes is a part of the process, you have to count that time as well.
That was what the OP said.
For me "typing code" is part of the thought process. These days, with GUI IDEs, and symbolic debuggers, there's almost no excuse to "measure twice; cut once," like we did in the "big iron" days.
I was trained as an artist, and the process of sketching is a lot like the way I work in architecting my code.
Also, I wouldn't call it "wasted" code. What was it that Edison is reputed to have said about 10,000 failed experiments?
"I now know 10,000 things that don't work."
I actually enjoy coding. I also really like my code to be clean, efficient, and useful. If code that I write is not all of these, I don't want it in my work.
I saw a chap that had a .sig that said something like:
"I hate code, and want as little of it as possible in my programs."
Few things make me feel as good as ripping out large swaths of code. It's like lancing a boil.
With coding, you are confined to formal syntax and semantics, but if the code (even partially) works, you can be more confident in your design.
With paper, you can plan as high-level as you want, with the danger of being too highlevel and overlooking things.
I cut my teeth, in the days when we were supposed to design the entire program; from start to finish, on a pad of paper, hand it to a data entry clerk, who would then create a deck of cards, based on the work.
It would then be scheduled for an expensive slice of time, and, if it screwed up, you got spanked.
It sucked. It really sucked.
Full disclosure: by the time I entered the field, punchcards had been replaced by VT-100 terminals and line printers, but the process was still the same, minus the data entry clerk.
These days, it's totally freewheeling. I try stuff out, screw up, kick myself, then try again.
I write about how I do stuff, here: https://littlegreenviper.com/miscellany/thats-not-what-ships...
What happens to the project if you get hit by a bus?
It’s over (but maybe not -see below).
Sucks, but that’s life.
This is a nonprofit, and they can’t afford to hire a large team of programmers. Heck, they can’t even afford me. I work for free.
The code, itself, is documented almost beyond belief. The only place I’ve ever seen documentation that even comes close to what I do, is in exposed Apple and Adobe code (where I got a lot of my inspiration). Don’t believe me? Look for yourself. My GH ID is the same as my HN ID[0]. All my code is like that. Look at any one of my projects. They are all heavily documented, and loaded with meaningful, relevant tests[1].
I’m a big believer in what I call “forensic design”[2], as well as really heavy-duty documentation[3].
So that means that, if there’s a developer with skill like mine, they’ll be able to take over the project in a relatively straightforward manner, but less-skilled people will probably be fairly stymied. They are likely to complain about my code, and rewrite from scratch, with typical modern crap code (and with typical modern crap results).
I’m not gonna do a crappy job, and make dross, just so some inexperienced jargonauts can mess up the project in the future. If that means it dies with me, then so be it. I’ve gone way beyond the pale, in delivering a project that can be maintained. If the people I deliver it to, mess it up by cheaping out on the hired help; that’s on them. They are the ones harnessing a racehorse to a plow.
I have a fair bit of prior art. I’ve written software architecture that has lasted decades, and has been taken over (and is still very much in use), by teams of skilled engineers. I don’t know if it’s still in use, as it’s been five years since I left my last company, but, at the time that I left, if you got their DSLR SDK, it had a C code API in it that I wrote in 1995.
[0] https://github.com/ChrisMarshallNY
[1] https://littlegreenviper.com/miscellany/testing-harness-vs-u...
[2] https://littlegreenviper.com/miscellany/forensic-design-docu...
[3] https://littlegreenviper.com/miscellany/leaving-a-legacy/