ed weissman

1. I write software: business applications. I love what I do. I love getting something to work right the first time. I love seeing people use the software I wrote to do their jobs and run their businesses. I can’t imagine doing anything else. 

2. The software I have inherited in all 88 companies I have worked at has sucked. I mean really sucked. Nothing to be proud of. Nothing to want to work on. I think it’s because business software is now where medicine was 100 years ago. 

So I have a choice. Work on other people’s crap or write my own. I have done both, but I have to write my own to be happy in this industry. If I could only work on other people’s software, I think I’d rather work in a grocery store. 

Starting a software business is the most direct way to do what I “really” want to do.

I realize that other people have different reasons; this is just one answer to your question.

Nothing interesting about my first story: I got a boring cubicle job in a large enterprise that needed 12 programmers to do anything, blah, blah, blah. But I did do some good work for a vice president who remembered me when he moved to another company, which leads to my second story, my real story:

He brought me in to his new company to do a consulting job to answer 2 questions, “What do we have to do to get Order Entry, Shop Floor Control, and Standard Costing written and running?” and “How many programmers do I need to hire?”

They had 400 employees, were missing all of these mission critical apps, and had only one programmer. But he was all they ever needed. I worked with him for 3 months and he wrote all of the software needed using tools and techniques none of us had ever seen before.

He did instant analysis and design, wrote disposable apps, did rapid prototyping, stepwise refinement, and extreme programming years before anyone ever heard of these things. He never wrote the same line of code twice, writing standard functions and reusable components. If he knew he needed something twice, he wrote a parameter-driven code generator on the fly and had me collect the parameters for him. He even coded in Boolean algebra and had an engine that converted it into production source code. He threw things into production long before anyone else would, figuring it was easier to just keep reworking them instead of waiting until it was perfect.

He was a one man shop in a $150 million company. He was smart, he worked hard, he loved what he did, but most of all, he didn’t know that “it couldn’t be done”, so he just did it.

Three months watching Dick build stuff, and I was hooked for life. I had to do it, too. And I’ve been doing pretty much the same thing ever since, pausing only long enough to add a few new technologies to my tool box along the way.

Sometimes I wonder what horrible cubicle I’d be wasting away in if I hadn’t met Dick and saw what was really possible.

“My goals with programming is to create web and desktop (mac, iphone) apps if that’s relevant.” 

Then you have it backwards. You should be building, not reading. 

Slow way: Read book —> apply what you learn 

Fast way: Write code —> Get stuck —> Find a book 

I know this is not intuitive, but trust me, it works much better. We all love the feeling of cracking open a fresh new book (or pdf) and bathing ourselves in all this newfound knowledge. But this method is not very efficient. Much of what you read you will never use and much of what you need you will never read about, no matter what the book is. 

Better to pick a project and just start building it. Come up for air every once in a while and consult whatever book fills in what you need to know to build your project. True learning comes from building, not reading. This method takes the best of both worlds and gets you to your stated goal much quicker. 

Simple. Whatever it takes without being uncomfortable about it. 

Things I will gladly do:

- phone interview with as many people as you like 

- physical interview until I think you have enough information to decide 

- share any of my work face to face 

- on-line third party evaluation (code test, personality, etc.) 

- review any of your system with you 

- code for you in person 

- sharing on-line information (including all hn posts) 

- doing up to 8 hours of free sample work 

- provide a referral if they are a better fit 

Things I strongly push:

- in depth discussion about the employer's situation 

- reverse interviewing employees with similar jobs 

Things I will gladly do, but only “after” a job offer:

- provide references 

- drug test 

- credit check

Things I will never do:

- have a generic resume (every one is uniquely targeted) 

- post any resume on-line 

- pay a fee 

- physical interview with a head-hunter 

- provide anyone else's proprietary information 

- "bad mouth" anyone else

Don’t ever do this. Just a few reasons… 

1. You say “during the application process”. Have you even met the hiring manager at this point? Worse yet, have you met “anyone” or are you just stuck in some automated process? Never forget that employment application is a two way street; you’re evaluating them as much as they’re evaluating you. They haven’t earned the right to see your code yet. 

2. This approach should be a red flag to any applicant. They want to see old code to evaluate you when they are 64 better ways to do that? Something’s fishy here - someone has no idea what they’re doing. 

3. Do not allow anyone to read your code out of context. You need to be there to explain the background, motivation, approach, and answer any questions. Cutting and pasting preempts yourself. Bring hard copy along only after the process has progressed far enough. 

4. Only bad things can happen. This is like being the first the mention a number - you can’t win. If someone wanted to hook up with you but asked for a dirty underwear sample first, would you give one? This is the same thing. 

5. If your code is proprietary, who knows where it could end up? You may also be violating confidentiality agreements. Not worth it. 

6. The employer-employee relationship is a never ending tension. You will always be “negotiating” money and working conditions, whether you realize it or not. Giving in to such an unreasonable request so early in your relationship marks you as a chump. You may never recover the equal footing you need (and deserve) in the ongoing relationship. 

7. If they have a problem, move on. You’re probably saving yourself a lot of trouble down the road. You sound like a competent developer who should have no trouble finding a job without bending over. So don’t. 

[Aside: Because of this kind of thinking, I never give references before being hired. In essence, I’m telling the prospective employer, “You decide.” They then have the right to rescind the offer if they don’t like a reference.]

Some people advocate: 1) private offices for each programmer, 2) free, nicely catered lunch every day (everyone eats together and bonds), 3) usual internet stuff - comfortable office, dogs, flexible schedules etc.

On one hand, a little voice inside of me cries, “Yes! This is what it takes to produce great software: a programmer-appreciative environment.”

On the other hand, another little voice claims, “This stuff is all well and good, but nothing more. It’s cosmetic, not functional, like putting perfume on a pig.”

I have been in many situations with Class A office space, private offices, catered team-building breakfasts and lunches, etc., etc., etc. and was ready to jump out the window. Why? Because the work sucked and all the window dressing in the world wasn’t going to change that.

Then I think back to some of my most favorite projects and remember the great work that we did. Sometimes in squalor-like conditions, sharing cubicles or tables, sitting in the server room with too much air conditioning or in the warehouse without enough, eating vending machine garbage and drinking old coffee because that was all there was.

Bottom line? The “work itself” is 100 times more important than the working conditions. Sure, everything being equal, I’d rather have nicer digs. But everything not being equal, I’ll choose the better project every time, no matter what the environment is like.

As a hiring manager, I look for someone who “gets things done”. No surprise that this takes many things: knowledge, skill, smarts, creativity, experience, team work, and maybe most important: attitude. You have just self-identified your bad attitude. If you think this is “draconian and insulting”, just wait until your knee deep in digital crap with customers barking at you all day long. 

“I cannot vouch for it’s efficacy as I’ve never used it when hiring people.” 

I can. Nothing works better. Period. If I have 30 to 60 minutes to find out how well you’ll perform, I’ll have you code and teach me what you’ve done. I don’t care what you’ve done before, your state of mind, or even if your code ever runs or compiles. If you’re any good at all, I’ll find out. If you’re a poser, I’ll find that out, too. And if you don’t want to play along, then either you’re a poser avoiding exposure or a prima donna who is saving me a lot of suffering down the road. 

I’m not trying to insult you, just give an honest answer to your (very good) question.

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
*
return();

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.

+===============================+
| >                              |
|                                |
|                                |
|                                |
|                                |
|                                |
|                                |
|                                |
|                                |
|                                |
+===============================+

You can find plenty of important life skills to be learned in school if you only look hard enough:

kindergarden - learn how to play nicely together

first grade - learn how to read and write

second grade - learn how to add, subtract, multiply, & divide

third grade - learn how to spell

fourth grade - learn how to play a musical instrument

fifth grade - learn how to appreciate great literature

sixth grade - learn how we got where we are

seventh grade - learn a foreign language

eighth grade - learn how to type and use a computer

ninth grade - learn how the world is put together

tenth grade - learn about other people in the world

eleventh grade - learn how to balance a job and school

twelveth grade - learn how to plan for and dream about the future

freshman year - learn how many other kinds of people are out there

sophomore year - learn how to chug a beer, fill a bong, and get laid

junior year - learn how to stand upon the shoulders of giants

senior year - learn how to find your place in the world

graduate school - learn how to play nicely together, all over again