not(AdviceForHackers)

I get a lot of emails these days from fellow hackers with [ distress | concern | depression ]. They're not looking for technical solutions or advice (which is good because I have neither), they're just not where they thought they'd be and are reaching out for *something*.

I try to make a point to answer all of them because, frankly, they're my most important emails. To me, the ones and zeroes inside my fellow humans heads are far more important than those on any computer.

If I built a Venn diagram of all of my responses, the intersection is significant. There are some things I end up telling almost everyone, regardless of their situation.

This is not(Advice). Just a bunch of observations from a fellow hacker who has also suffered and learned...

1. You don't have a time machine.

So many fellow hackers say, "If only I hadn't..." with "quit my job" being the top instance.

You can't "should have". You can only "do". You don't have to forget what happened in the past, but you don't have to overemphasize the importance of its input into your future.

My favorite example:

2 people are travelling from New York to San Francisco. One drives directly from New York to Chicago. The other drives to Florida, Texas, Tennesee, and then Chicago. They are now both in Chicago, well fed, rested, and ready to go. How should their plans differ? (Hint: Except for rare exceptions, they shouldn't.)

It doesn't matter how you got where you're at. It only matters where you're at, who you are, and what you've got.

2. You can't read others' minds.

I often hear things like, "If I only knew what she wanted, I would do it." You don't know. So ask. We humans are not connected via USB 3.0 (yet). Until then, we must talk to each other without fear. That usually improves our chances of success significantly.

3. There are no rewards or punishments, only consequences.

Life's not fair. With software, unknown input + known process = predictable result. In life, known input + unknown process = consequences. We spend a lifetime learning the processes, so we should get better predicting the consequences. When you were 16 are wrote that cool software that nobody wanted, you were disappointed. Now you should either adjust the input or stop being disappointed. You'll never be perfect, but with continuous learning, you should get pretty good knowing what will work and what won't.

It's not about luck. It's about adjusting the controls to maximize the possibility of desirable consequences. You didn't do that as well as you would have liked this last time. You'll do better next time.

4. Don't order a taco at a Chinese restaurant.

Many hackers are disappointed in the responses of others in their lives. "If only more people clicked that button." "If only my cofounder worked harder." "If only that angel got it."

Sometimes we expect things from others that they are incapable of giving. It's hard for we hackers to believe that it's so difficult (or impossible) for <Person A> to do <Task B> or understand <Concept C>. We might as well order a taco at a Chinese restaurant. (Hint: They don't have any.)

When others don't respond the way you expected, maybe it's because they couldn't or didn't know how. Don't blame them. Just order what they've got.

5. You are a Chinese restaurant that doesn't serve tacos.

Sometimes a friend or loved one says something like, "You had it all! You made more money than anyone I know and you threw it away for a silly dream. You could have had and done anything you wanted with a salary like that."

Whenever they do, they're ordering a taco from *your* Chinese restaurant. They think you're something you're not and they want something from you that you don't have to give them.

In general, most normals get a greater percentage of their satisfaction from mainstream thinking, good times, and "stuff". They don't understand the hacker mindset of getting satisfaction from building and achieving.

That's OK. Being different isn't the problem. Forgetting that we are is.

6. They love you. They want to help. They're always right. Pick two out of three. (Hint: It's the first two.)

I often hear things like, "My father criticizes me for <x> and I feel awful." You can only feel awful if you believe him. You only believe him if you think he's right. But as hard as it is to believe, sometimes he's actually wrong. This is probably one of those times. Get used to it.

7. It's all in your head.

It may sound like some enlightened Zen kind of thing, but it really is true. But knowing it and living it are two entirely different things.

It's easy to say things like, "I will manifest <y> in my life," especially for us hackers because we are used to making something seemingly out of nothing. But when we appear to not succeed at building something right out of our head, it's easy to dismiss our our responsibility and blame something external (time, money, support, luck, etc.)

It really is all in your head. You may not be ready right now, but eventually you will be. Then you'll try again.

8. I care. And I have a feeling I'm not the only one.

The single biggest response I ever get is something like, "Thank you. It's not what you said, but the fact that you responded that means so much to me."

Feel free to email me any time. Any feel free to engage others, too. But don't get concerned if they don't respond. Their Chinese restaurant doesn't serve tacos yet.

What if my problem has many competitors?

Here’s an idea: find “someone else” with a problem and work on that. This works especially well if the someone else is in business, very busy, and has some money. Chances are better that your solution to their problem won’t have much competition: if it did, they would have already gone with it.

I know this is the opposite of “scratch your own itch”, but I always found that advice overrated. I have always been much more successful scratching other people’s itches.


How do you become a "fearless programmer"?

I have always been a “fearless” programmer, but never realized it until recently. Here’s how:

“Fear of not knowing the best way to do things (best practices).”

The sooner you realize that there is never a best way of doing anything, the sooner you can release this silly fear. Some ways are better that others, but “any way” is better than “no way”. Just get the thing done. Later, when you refactor, you’ll have the best of all worlds: code that did the job right away, a better way of doing things, a satisfied customer, and a great learning experience.

“Fear of not using the right tools and languages.”

Give me an adjustable wrench, 2 screwdrivers, and a big hammer and I can fix just about anything. Same thing with programming. I’m too busy getting work done to learn every new tool or technique. As I’ve told many programmers over the years: “Whatever you can do, I can do in BASIC. Maybe not as pretty, but probably just as fast and just as effective.”

“Fear of errors (especially compiler errors).”
 
You’re in the wrong business. Errors are what point you in the right direction. The sooner you learn to embrace errors and use them to refine your work, the sooner you’ll become fearless (and better).
 
“Fear of schedules.”

“I see only one move ahead, but it is always the correct one.” - chess master Jose Raul Capablanca. That’s what my schedule looks like. One item. One day. Project managers can’t stand this, but then again, I get way more work done than they do.

“Fear of publicity (what will other programmers think about this code?).”

I never publish my code. Ever. Users get to give me feedback, but I don’t care what other programmers think. Sure, I learn from them, but never in the context of reviewing the code I wrote. I learn from the code of others and apply those lessons to my own work.


Should a systems analyst code?

I hate to break the news to you, but “systems analyst” is a job title that’s pretty much exclusive to the enterprise world. For the most part, start-ups don’t really have a place for “business/system analysts”. Let me explain…

School of Thought A: Call it SDLC (Systems Development Life Cycle), the project approach, or the waterfall approach goes something like this: Define a need, conduct analysis to answer the question “What”, conduct design to answer the question “How”, program, test, program, test, compare to the Functional Specs from the Analysis Phase, conduct User Acceptance Testing, promote, deploy, repeat anything as required. The more rigorous the documentation and project management, the better.

School of Thought B: Build something ASAP. Get it out there ASAP. Get feedback ASAP. Iterate
indefinitely.

For the most part (I’m sure there are many counter-examples), enterprises employ School of Thought A and Start-Ups employ School of Thought B. There simply isn’t a need for systems analysis in School of Thought B. By the time you’re done analyzing, someone else is servicing the customers you sought.


My advice: Combine a love for building stuff with your love of systems analysis. They go perfectly together. In fact, we now have a name for that: “programmer/analyst”.
 
The systems analyst who can code is a better systems analyst because he can test/evaluate his ideas. The programmer who can conduct analysis is a better programmer because he knows what to work on. This may not be what you wanted to hear, but you’re in a perfect position to do both, so do it.


How can I find ideas?

Here’s an idea: get a job. After a year, you’ll have plenty of ideas, maybe even one of your own.

I hate to rain on anyone’s parade, but the thought of begging for ideas is just so alien to me. The best predictor of your success in any endeavor is your own determination. With someone else’s idea, you’re much more likely to bail at the first sign of difficulty. Once you get a little real world experience under your belt, you’ll find plenty of opportunities to encounter something for which you’ll have real passion.

Your chances of success increase astronomically when you’re working on something you “have to do”. The only way to know if you “have to do it” is to have a little background and experience with it. Trading ideas like commodities seems like the least likely way to find something you’ll be passionate about.

OTOH, a “boring job” can be an incredibly fertile environment for start-up ideas. You’ll learn what people want, see what works and what doesn’t, and be much more adept at identifying opportunities. Oh, and get a chance to bank some money so that when you do start working on your passion, you can concentrate on that instead of begging for funding.

Sometimes the easy way out is just that: the easy way “out”. Get a job and pay your dues. You’ll probably be glad that you did.


What should a mediocre programmer do?

“I’m really just a mediocre programmer with really good domain knowledge”

Your problem is that you have no problem. Let me explain…

I believe that the quality of a programmer is not how much you know, but what you can do with it. So if you have “really good domain knowledge”, then you probably aren’t a mediocre programmer at all, you’re probably a good programmer or even better.

Like many other programmers, I love to check out the latest cool stuff people are doing. Then I hear the 2 voices in my head. One says, “That is so cool - I have to learn that!” The other says, “Big deal, I could do that in BASIC. I may need a few more lines of codes and a couple of hacks, but it will still do the exact same thing.”

It’s tricky to balance all the cool stuff going on with your ability to “just get stuff done”. You will never learn everything. You will never become the expert at more than one or two things. It’s great to “learn”, but not at the expense of “doing”. You need both. There were many times I had to build something with my limited knowledge and wished I knew more. But then I built it anyway. Something built with limited resources today is better than something built perfectly tomorrow.

If you’re unhappy with your job but like coding, then either find another job or start something on the side. But please don’t fall into the trap that you aren’t good enough because “someone else” knows “something more”. That will always be the case. You can’t win that battle.

Just do the best with what you have and make a practice of adding to it a little at a time. Get satisfaction from the benefits you provide others with what you know now.


What would you advise your younger self?

Find a customer first.

This is the biggest mistake I made in my twenties, and it’s such an easy mistake to make that I continue to make it now even though I know better. I continually have ideas popping into my head. And I act on many of them. So much cool stuff. If only I can get this working, it will change the world. And I love being in this mode; it’s so much fun. And it can lead to great things…

But you have to know when you’re going too far and wasting time, money, and energy. At some point, you have to find a customer. Any kind of customer, just someone besides yourself who wants what you’re doing.

When I have had partners, they forced me into this thinking, directing our energy to where the demand was.

This always worked out well.

When I worked alone, well let’s just say there’s tons of cool stuff still on the drawing board that led nowhere.
 
Don’t let that happen to you.

I’m not saying to suppress your creativity or experimentation. I’m just saying the point you need to find a customer is much earlier than the hacker mindset intuitively expects.
 
It there was one thing I could change in my twenties, it would be to adopt this thinking.


Is this a good way to get motivated?

“There’s a way for me to make some money, but it requires that I setup a fairly complicated spreadsheet to monitor several variables.”

A “complicated spreadsheet” isn’t a requirement, it’s a roadblock. You’re making it harder for yourself by putting obstacles in front of yourself and then wondering why it’s so hard to make progress.

“I want to be rich. Filthy rich, even.”
 
Getting rich isn’t the goal. It’s a byproduct. You never even mention what your startup is going to do, who it’s going to help, or why you absolutely positively must do it. If you have something you “must” do, identify it and focus on it. If you don’t, find it. Everything else, including money, is just a detail.

“I take a break to ‘clear my head’.”

Clearing your head isn’t a necessary step, it’s an excuse. Again, if you have something you “must” do, you head is already plenty clear. If you don’t, then what are you clearing your head for?


In summary:


1. Find what you “must” do.
 
2. Start doing it. In case you don’t have something you “must” do, then just do something, anything. The process of doing will probably help you find your mission. The processes of thinking, preparing tools, and dreaming about money probably won’t.

A couple of minor pointers that have helped me:

1. If you have 2 computers, make one for work and the other for internet and “put them in different rooms”.

2. Throw your TV set into the dumpster.

3. When you have code to work on, be at your terminal, working on it (Mode 1).

4. When you don’t have code to write, be anywhere but your terminal with pencil and paper handy (Mode 2).

5. Start every day in Mode 1 and end every day (probably in bed) in Mode 2. Ending the day in Mode 2 in requisite to being able to start in Mode 1 the next day.

6. Take care of yourself.


What’s it like to be a programmer?

“1. What are some qualifications of a computer programmer?”

The two most important qualifications are a love of details and a simultaneous appreciation of the bigger picture. You have to understand the landscape that your software will fit into. Then you have to be willing and able to dig down deep and be comfortable building stuff at the lowest level of detail. This takes a great deal of logical thinking, attention to detail, and personal focus.

“2. What is the best part of being a computer programmer? The worst? The most challenging?”

The best part is getting something working for the first time where nothing was there before. For me, this is so exciting that I still I do a “happy dance” every time. The worst part is the long hours alone. There’s really no way around it; good software takes time and almost everything is done by someone alone at a terminal. The most challenging is finding a project big enough to not be boring but small enough that’s it’s too difficult to make good progress.

“3. What’s the salary range in this career?”

As an employee, $35,000 to $200,000. As a company owner, $0 to billions. Either way, the range is very wide and depends on many factors, some outside of your control. Like any other profession, you should be a programmer because you love to program, not because of how much money you’ll make.

“4. What is a typical day in the life of a computer programmer?”

I bet there are as many typical days as there are programmers, so I’ll just share mine. My day starts at my terminal, making changes to my current program based the mark-ups I did to my hard copy in bed the night before. I spend most of the day at the terminal writing code, changing it, trying it out, and taking occasional notes. I avoid interruptions as much as I can. I have a regular lunch and dinner and some social life, but not too much. Every day ends the same, in bed with whatever I worked on that day, reviewing and marking up. Incredible attention to detail is required and this is how I do it.

“5. What is some advice you would give to young computer programmers?”

Just build something. Nothing can be more important. Whenever you need to learn something, find a way to learn it, whether it’s a class, friends, or more likely, a book or website. It you want to be a programmer badly enough, you’ll find this approach natural. If you don’t, you won’t.

“6. Is it easy to find a job as a computer programmer?”

If you’re good (and can prove it), yes. It not, not so much.

“7. What was your most exciting project?”

A computer program that wrote other computer programs.

“8. What skills do you think young programmers need for the job?”

The ability to think clearly and logically, good written and verbal communication skills, the discipline to keep working when they’d rather be with other people, and the determination to see something through to completion.

“9. What improvement does computer programming give for human life?”

Computer programming makes software that frees people up to think about and do things that weren’t possible just a few years ago. The possibilites for those people are endless.

“10. What is the future direction of computer programming?”

This is always hard to predict, but I’d guess the direction will head away from writing all of your own software toward connecting a lot of already written software to accomplish the same thing.

“11. Would life be a lot worse without computer programming? How much? Why?”

Just compare life in a country with advanced technology to one without. Computer programming doesn’t have everything to do with the difference, but it does have a lot. Much of today’s advanced lifestyle has resulted from modern technology. Much modern technology came from software. All software came from computer programming.


How do I find passion for my work?

The reason you’re not passionate about your work is because something is missing. Identifying what is missing is your first step in determining where to go from here.

I have been in a similar situation. Always working. Important stuff. Sometimes cool, often not. But something was always missing.

Architecture not rigorous enough. Inadequate data base design. Insufficient requirements definition. Lousy code base. Unable to scale. Unable to expand or handle completely new features. But I always managed to make it work anyway. Then it occurred to me, if such mediocre systems were able to produce adequate results in commercial environments, what would be possible with great systems?

So now I’m building a framework/architecture/environment that beautifully handles everything I thought was missing before. The passion is built-in. Instead of, “Look at me, ma!” now it’s “Look at this, everybody!” Where do you go from here? Fill in the gaps that should have been providing passion all along. That oughta keep you busy for a while.