My name is Ed Weissman and I've been programming professionally for almost 40 years.
I've done work for many companies, both enterprises and small/medium businesses. I've functioned as an employee, a contractor, and a vendor. I've worked in many industries, almost always on business systems.
I started out on IBM mainframes, moved to mini-computers, then to PCs, and finally to web-based technologies.
I've started three businesses, two with partners and one alone, selling both services and products.
I've worked with hundreds of people on over a thousand projects and encountered over a million lines of code.
I've witnessed a lot of business and technology, some great, some good, and some not so good. I've always loved what I do and can't imagine doing anything else.
I've formed lots of opinions and freely shared many of them on-line. So I decided to compile my favorite Hacker News contributions back in 2011 as "The Best of edw519". This is the second edition, a continuation of my original project. I've removed some things, added others, and cleaned up the rest.
I never get too technical. There are plenty of other resources for that. Inside you'll find the opinions of someone who's been in the trenches for years and isn't afraid to say what he thinks. Whether or not you agree, understand, or even care, I hope you find something of value. That's the best I could hope for.
Because you asked for it.
I started commenting on Hacker News when I discovered it ten years ago. For a computer programmer, it had lots of cool articles, interesting commentary, and most of all, like minded souls. It became my on-line home - the location may have been virtual, but the results have been all too real.
Little did I know where this would lead...
Thanks for all the interesting discussion and encouraging feedback, both on-line and by email.
Lots of people claimed benefits from my comments and suggested that I do more, either by blogging or writing a book. My response was always, "I do write. I write software." I was always afraid that devoting time to writing prose would take away time from writing source code. It took a while before I realized that this wasn't a zero-sum game; different kinds of writing can compliment and even enhance each other.
The feedback that finally got me over the hump was this comment from an anonymous poster:
"Seriously, have you ever thought about writing a book? I learn something new and valuable every time I read a comment of yours, since your comments almost always contain really good tips. I for one would buy that book for sure." (Thanks, Mom.)
My comments have visited far more interesting places than I ever have:
"Harvard Business Review"
"mixergy" by Andrew Warner
"SKMurphy" by Sean Murphy
"allExceptTech" by Ketan Khairnar
"FundFindr" by Bret Conkin
"University of Washington Orthopaedics and Sports Medicine" by Jonathan Jacky
"Why does everything suck?" by Hank Williams
"Sixteenth Letter" by Melissa Chang
"Back of the Envelope" by Mr. E
And finally, some of the nice things people have said about the comments of my on-line persona:
"...edw519, most of his stuff is thoroughly thought-provoking..." - Matt Mazur
"The Best Comment Ever (No, I Didnít Write It)... by edw519, writing an incredible comment on an otherwise unworthy Hacker News story." - Mark O'Connor
"...another great comment from edw519..." - Sigit Nurseto
"...an excellent follow-up comment at HN by uber-poster edw519..." - D. C. Toedt
"...Ed Weissman (edw519 on HN) had another great comment recently on Hacker News...and he offers a great list of reasons why..." - Sean Murphy
"From Hacker News commenter edw519 comes this gem..." - Andrew R. Freed
"...Hacker News reader edw519 makes a great observation..." by Rams
"And then there are the folks who have such an intelligent and unique voice that you can tell who the comment is before you see their username (patio11 and edw519, to name two)." - Ryan Waggoner
Thanks to all of you. I hope to pass on your positive energy to others in some way. This book is my first step.
I built this book the way any self-respecting programmer would: with lots of shortcuts and software.
Notice I said "built", not "wrote". The contents were already written, as contributions to Hacker News, a large on-line community for computer programmers.
What I did:
First, I scraped the interwebs for every comment I ever made on Hacker News and put all 4,000 of them into a hashed database on my c: drive.
Then, I converted the text into something more presentable, removing formatting, control characters, and cuss words. For example, whenever you see "crap" in this book, you can bet that it was something much "stronger" in the original.
Finally, I wrote a program to turn those comments into a usable book. Some of the things that program does:
1. It displays the comments, one at a time or in groups, enabling me to cruise through them very quickly, using only arrow keys.
2. It sorts the comments five ways: by descending number of words, by descending points, by descending date, by descending weight (a secret formula), and in output sequence.
3. It enables me to quickly classify any comment by suitability, chapter, and sequence.
4. It filters the comments by classification.
5. It enables me to drop down and edit any comment.
6. It automatically classifies unread comments based upon similarity to classified comments and some rules. (The idea was to classify the first 300 comments and have the software classify the remaining 3,700. I realized this capability was unnecessary when the book would only contain 256 entries. Oh well.)
7. It cuts the book in multiple formats, ready for distribution.
Like a typical programmer, I often got confused about what the real product was. I spent more time on the software than the contents of the book. Then I decided to get the book out and finish the software later.
The single most important thing I do to "achieve laser focus and concentration" is to work in such a way that I don't need "laser focus and concentration" to get my work done.
This has to be done the night before.
I always quit all online work at least 2 hours before bedtime and print whatever I'm working on. Then I go into any other room with program listings, blank paper, and pens (especially red!) and plan out all of tomorrow's work.
All analysis, design, and refactoring must be done at this time. I do not allow myself to sleep until the next day's work is laid out. I also do not allow myself to get back onto the computer. The idea is to have a clear vision of what I am going to accomplish the next day. The clearer the better.
This does 2 things. First, I think about it all night (maybe even dream about it). Second, I can't wait to get started the next day. I always wake up and start programming immediately. Once I get going, it's easy to keep going. Any difficulties are probably because I didn't plan well enough the night before.
1. Start with the answer, then work back.
2. Name your variables so that anyone will know what they are.
3. Name your functions so that anyone will know what they do.
4. Never write the same line of code twice. Use functions.
5. Assume the user doesn't know what they want.
6. Even if the user knows what they want, assume they can't verbalize it.
7. The user always knows what they don't like. Prototype often.
8. Be prepared to dig down as many levels of detail as needed to understand.
9. When you're stuck, turn off your computer.
10. Don't turn your computer on until you have a specific task.
11. Beauty is important, but delivery is more important.
12. No variable should be fully contained within another variable.
13. All variables should be at least 3 characters long.
14. Use the right tool for the right job.
15. Almost any tool can do the job. Some are better than others.
16. Benchmark often in order to learn what happens under the hood.
17. Try something that's never been done. It may be easier than you thought.
18. Remember the patterns you've used before. You'll use them again.
19. Keep it extremely simple at first. Complexify as you go.
20. Code every day.
How I Write Code:
1. Copy the smallest piece of code I've already written and change it slightly to do something really small. Get it working perfectly.
2. Add a little bit. Get it working perfectly.
3. Add a little bit more. Get it working perfectly.
4. Repeat until it's not so easy to add anything, even a little bit. Print a hard copy. Holy crap! Did I write all that?
5. Mark it up like crazy with a red pen. Combine similar code into common functions. Rename variables. Rename them again. Rename them again. Rename them to what they originally were, but without vowels. Restructure unwieldy functions. Rewrite the stuff I can't believe I actually wrote myself.
6. Sit down at terminal and enter changes. Save every version (even though I never look at it again). Get it to work perfectly (again). Holy crap! What did I do? It's totally broken! Debug, debug, debug. Good. Now it runs perfectly. Time to add more: go back to Step 1. (Except every 5th time through this loop: Scrap it all and rewrite it the way I should have in the first place.)
7. Repeat until dead.
This question reminds me of the greatest cook ever, my grandmother. She used no technology whatsoever. All of her tools had been her mother's which were probably manufactured in the 1800s. She chopped everything by hand in a wooden bowl. If anyone else helped her with the chopping, everyone at dinner could tell. She never used pencil or paper and measured nothing. She stood in line at the farmer's market, the butcher, or the grocery store and inspected every item. And absolutely nothing I have ever eaten since, in any restaurant or home, has been remotely close to hers. It was magnificent! And I miss it so much.
I'd like to think I have almost as much passion about my work. I use the most primitive tools, 24 x 80 green screen editor, no framework, no IDE, no debugger, and mostly pencil and paper. I savor every byte just as I imagine my grandmother savored every little detail of her cooking. I'm not trying to save time or be fast, I just aspire to creating Grandma-quality software. I only hope my software brings someone the same joy her food brought all of us.
I've used many different tools. And I rarely care how fancy they are. Ironically, the simpler, the more joy I have found along the way.
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 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 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.
BIG disclaimer: I have NO formal training.
1. Tools. I generally shy away from tools. I just don't like using anything that makes me more productive when I'm programming. I prefer to type out every line of code, occasionally cutting and pasting from the same program or something similar from the past, but not very often. I want the writing of code to be painstakingly slow and deliberate. Why? Because productivity is not the objective. Becoming one with my project is. I may not start as fast as others, but that doesn't matter. It's not how fast you start. It's how soon you deliver a quality product. Like memorizing a speech, cranking out the code by hand makes it firmware in my brain. It's not unusual for me to crank out 300 lines of code and then be able to reenter them on another machine from memory. So when it comes time to debug, refactor, enhance, or rework, those cycles go very quickly; that code is already in my brain's RAM and it got there the hard way.
2. Simple Algorithms. Yes! I love this example:
* EnterOrders 08/31/10 edw519
I now have a working program! You say you want more features? No problem. Let's start enhancing it.
3. Debugging. I don't. I've seen 25 different debuggers and I hate them all. Print() is my friend, especially beyond the right fold. Better yet, write code that doesn't need to be debugged (See #1 & #2 above.) (Of course, this is much harder with someone else's code.)
4. References. Don't need no stinkin' manual. I have become extremely adept at about 4% of what's available to me, but that 4% accomplishes 98% of what I want to do. (OK, I'll refer to a manual when I need something from the other 96%, but that doesn't happen too often.) We could talk about all kinds of other things too, like variable naming, how to iterate and branch, and never typing the same line of code twice, but this was a nice starting subset.
Wanna know the biggest difference between you and me? I'm pulled. You're pushed. Let me explain:
I love building stuff. Nothing gives me a bigger rush than getting something working the first time. But I couldn't care less about the technology. If an abacus, two tin cans on a string, or some BASIC code on a Kaypro II did the job, then that's what I'd use.
What I really care about is how my software is used. And who uses it. There's an endless stream of people who need stuff and an endless stream of problems to solve. For individuals, groups, and businesses. When I encounter a new problem to work on, I use whatever I can apply in my tool box. Sure, I have to upgrade that tool box every so often because I need more to solve my problems, not because I love the toys so much.
You sound like the opposite. You love the toys and look for places to use them.
My suggestion: Take a break from the technology and put yourself in more situations where people can share their problems. This will give real human meaning to the technology. I bet you'll be chomping at the bit to build something for someone in no time. For me, being pulled by a demand motivates much better than being pushed by a supply. Maybe it can be for you too.
"Work effective hours, not necessarily long hours:"
The best trick I have ever figured out for doing this is to separate all activities into "in front on my computer" and "away from my computer". If you are working ineffectively in either mode, switch modes. If you are still working ineffectively, consider a break.
I often sit in front of my computer, writing code, refactoring, or testing and realize that I'm getting nowhere. Then I conclude that the reason I'm not making progress is because I'm not quite sure "what" to do.
Determining what to do is an activity that I have found much more effective away from the computer. So I log off, grab pencil and paper and go somewhere else, anywhere else. As soon as I have something I'm sure I want to code, then (and only then) do I return to the computer.
This works both ways. If I'm away from my computer, but feel I'm not creative enough, then I just decide to write something, anything, and go write it. Sometimes just getting the smallest things done opens the doors to getting bigger things done.
I'm guessing my split would be like:
sales & marketing - 10%
analysis - 15%
design - 5%
development - 50%
implementation - 10%
support - 10%
Testing is not a phase, it's included in everything. Implementation includes deployment, training, and documentation.
Sales and marketing were never problems. There is business everywhere. I mention what I do everywhere I go (who doesn't), and find business almost anywhere. Everyone uses software these days and everyone needs something. I've gotten 5 figure deals at parties, family functions, networking events, and mostly from word of mouth.
I love to program, but I also love to talk about what I do. I may not be typical, but isn't helping people with cool tech what it's all about?
In my mind, the problem isn't the time needed for selling and marketing. The real problem is that this kind of business (consultingware, one-off packages, lite package with customization, whatever you want to call it) isn't scalable.
If my competitive advantage is better value because the boss (not some lightweight on an 800 number) is supporting you, then it's also my biggest limitation. I only have so many hours in a year. Sure, I can extend myself with advanced methods and technology, but sooner or later, I hit my limit. That's why it's so important to find a way to convert your consultingware business into a product business. Not an easy feat, but surely worth the effort.
Some of the things that have worked for me:
- Decouple analysis from coding. There are some things that should NOT be done in front of a terminal. Get a pencil and paper and go somewhere else. By the time you're done, you'll have plenty of stuff to code. (I have found that the main reason I get stuck is because I haven't spent enough time away from the terminal laying things out. I'm always in too much of a hurry to get back to work before I'm ready.)
- Get a customer. They'll give you something specific to work on. If it's maintenance, all the more reason to get to just dig in and get to work.
- Ask yourself the question, "How am I making this too hard?" If you listen to yourself long enough, you'll probably get a good answer and a fresh approach.
- Reduce scope. Remove outlying cases. Solve only for the most probable case. Get that working perfectly. The process of doing this will probably shed a lot of light on how to set up structure that will also handle the outliers.
- Back up your current version and the go wild on it with some crazy approach. Knowing you have a good backup frees you up all the more. At the end of the day, if you have something cool, keep it. If not, just restore your backup and throw away today's work. You may have wasted the code, but you didn't waste your time. You probably got the juices flowing again.
- Backup your current version and forget about it. Wipe the slate clean and start over completely. You won't have to worry about satisfying all the overhead you've already created. After a day or two, keep either the original version, the new version, or more likely, you'll have a new project: combining the best of both. In any case, you'll be busy working again.
- Set the project aside and work on something easy and fun that no one needs and provides little value to anyone. The byproduct is that suddenly, you'll discover you're working and enjoying it. The next thing you know, you'll want to go back to the more difficult project.
- If you're stuck on something, post your dilemma on-line. Read the responses. You may get a different approach that you can play with. And even if you don't, you won't feel so alone. That may help.