ed weissman

Smart. Motivated. Works well with others. Has passion. Good problem solver. Detail oriented. Able to focus. 

In order to be a great programmer, how many of these are important? All of them. 

How many are necessary? None of them. 

I once had a calculus professor who said, “Many students are simply unsuited for the sciences.” 

I disagreed with him then, and after many years of work experience, I disagree with him more than ever. I firmly believe (with some exceptions) that almost anyone can become great (or at least very good) at almost anything. I’ve seen it over and over again. 

I have worked with hundreds of programmers over the years and screened thousands of others. Almost all of them consistently delivered substandard work. Not because they weren’t smart or motivated or capable. More likely because they weren’t taught properly and were in terrible environments. 

Teach someone how to do the job properly, give them an environment in which they can thrive, give them a chance to do quality work, and treat them like human beings. Then watch what happens. But companies are too stupid or lazy to do this, so they think they’ll just hire talent and dump them into their already sour environment. Fix the environment and let regular people become great. 

Made. 

Here’s the dirty little secret that no one wants to talk about… 

The purpose of “assisters” like frameworks and higher level languages is NOT to make good programmers more efficient. It’s to make mediocre programmers more likely to produce “something” of value and to make poor programmers capable of producing anything at all. And if the bell curve tells us anything at all, it’s that these “tools” target 90% of all programmers. But think about it, my fellow top 10%, do you really need all this stuff? If you’re working alone or on a small team with a clear objective, haven’t you always had everything you needed with low level tools? If you need any higher level tools or reuseable components, haven’t you already been building these all along?

Sure it’s fun to play with new things and learn from others, but when it comes time to really produce, don’t we all know how to (and need to) roll with what we know? 

The need for frameworks and high level languages only becomes apparent when we grow so large that we can’t find enough senior hackers. Only when you dip down into the mediocre masses do you need this help.

What’s good about it?
What’s good about it?
What’s good about it?

(I had to ask multiple times because we all know that the first couple of answers would be, “Nothing”.)

Every job, no matter how boring, is loaded with “stuff” that you “can” use to contribute to your long term progress.
 
It may be access to a user who’s an expert in their field and would love to share their expertise.

It may be a project that needs to be done, but no one else has time. And you can learn a lot of unexpected stuff from doing it.

It may be lots of interesting data on their hard drive that you can learn a lot from just by transversing and/or organizing.
 
It might even be proximity to a quiet coffee shop where no one would miss you.
 
It could be anything.
 
So if you’re stuck, then it’s your job to turn lemons into lemonade. (Practice turning lemons into lemonade is an invaluable skill on it’s own; just ask any entrepreneur.)

Now close your browser and make a list of 10 things you can try to get “some” value out of this job while you’re there. Then open your browser back up and let us know what they are.

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 have not spent the requisite 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 outlyers.

- 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.

“Inability to absorb too many details verbally” = personal fortitude to insist that others show a modium of discipline and occasionally write down what they want 

“Inability to multi-task” = ability to focus 

“Inability to manage or even to see certain classes of mundane details” = ability to distinguish the difference between and “issue” and a “detail” 

“Inability to organize” = lack of the need to organize because of intense focus on the most important thing 

“Capable of working through entire books of information” because of the ability to distinguish between “issues” and “details” (see above) 

“Capable of coming up with pretty good project ideas on his own” = creativity

“unusual degree of empathy” = understands the “big picture” 

“Faults tend not to show up terribly badly” but only to those tuned in to the “superficial”, not the “important” 

“If he can team up with…” = understands synergy 

“Is this guy sick?” = a one eyed man in the land of the blind

Selling and marketing, knocking on doors, and touting your products and services “shows you as an idle developer”? 

Actually, it shows you as a go-getter, exactly the type of person I’d want working for me. 

The biggest difference between the top 1% and everyone else? They never stop selling.

I’ve done the same thing as OP and it works. Better yet, if you have office space, invite your neighbors over for wine and cheese (or beer and soda) Friday after work. Socialize and share. They may not become customers that day, but when they (or someone they know) needs what you offer, who do you think they’re gonna call? 

“I took a step back and immediately saw absolutely no redeeming value of what I had just done, and this made me feel incredibly sad.”

I would rephrase that as, “…absolutely no redeeming value “at this time”…”

You have just planted seeds. Of course you can see no “redeeming value” right now. If you just planted seeds in your garden out back, you wouldn’t see any results there either, “today”.

But just as the seeds in your garden will deliver results in a few months (provided you care for them), the seeds you just planted in your little “hairbrained” project, will also reap dividends. You just don’t know when or what.

Sometime in the future when you least expect it, the lightbulb will go on and you’ll figure out a cool solution to some other problem. What you don’t know now (and probably won’t even realize then) was that what you did today stirred a few neurons to enable that light bulb to go on in the future.

As hackers, “everything” we do is either planting seeds or reaping harvest. If you didn’t see a harvest today, that’s because you were planting seeds. Just keep on working and trust the process; that’s how we all get better at what we do.

“1. OO code is less performant than procedural code” 

Never forget, the primary purpose of OO is to help “us”, not our users. OO is a great way to get junior people thinking a certain way, set standards, and make maintainability a little more manageable (usually). The only thing it really does for our users and customers is help us help them by making our lives a little easier. 

“2. The backend is the most important part of development” 

Sometimes I think we get this backward. Think about it. You can do almost anything you want on the back end and no one notices unless there’s a problem. The client side is a whole different story. It has to work perfectly no matter what browser or resolution your user arrives with, and it has to do it using a limited number of technologies, a small footprint, and with limited round trips to the server. It’s almost like it’s 1965 all over again. 

“3. Graphical designers are good at user interface design” 

UI design != UI function. It doesn’t matter how pretty it is if the user can’t figure out what to do or if it doesn’t “function” as expected.

“4. The existence of a superior programming language” 

Yea, some languages are better than others for certain things, but a expert practitioner of a seemingly inferior technology is almost always better than an average practitioner of a superior technology. To this very day, my mother can still “print” faster than any of us kids can “write”. Amazing. 

“5. XML is more economic than a DB” 

XML serves its purpose of being autodocumenting quite well. That’s all it does well. If you need to parse for any reason, almost any other format blows it away. 

I can attest that trying to hit a homerun and hitting only a single or double is still great. 

I tried to prove Ferman’s last theorem (years ago) for my senior project. I didn’t :-) But I turned in what I had and got an A+ and 4 invitations to grad school based on that paper alone. 

I entered my fraternity into a contest for Chapter of the Year. I didn’t care about the trophy; I only cared about what would happen to us by doing all the things needed to try for it. It worked. 

I have often tried to solve the biggest problem at some of my customers over the years, but didn’t. But all the little things I had to do to make the attempt turned into pretty good products and services anyway. Nothing wrong with trying to hit a homerun as long as you keep your wits about you and don’t let it become and win or go home proposition. 

If you come to the realization that work in itself isn’t evil, you can stop living your life as a waterfall-planned software project too. 

Nothing wrong with waterfall-planning if it’s done properly. Problem is, it usually isn’t. 

I understand that sometimes you need to release early and often. This is when you can’t conduct proper anaysis. Why not? Because you’re trying for a home run building something big and you don’t know where your project will take you or who will eventually use it. Like a Web 2.0 or social site. 

But for the rest of us, waterfall-planning is just another name for the Systems Development Life Cycle (SDLC), which is an excellent way to develop systems. But you must conduct analysis first. You must answer the question what before you examine the question how. 

Most developers do not know how to do this. How can you tell? When their waterfall phases take too long (more than a month for analysis for most projects). When they say things like, The user doesn’t know what he needs. Yes he does. You just have to keep digging until you know. 

Once a good programmer learns how to conduct analysis he becomes a good developer. Then projects become like shooting fish in a barrel. You biggest problem will be convincing your customers that you can do what they think can’t be done.