ed weissman

Long gone are the days when the “system analyst” met with the users, wrote tight functional specifications and handed them to the “business programmer”. In any organization that actually gets anything done, the two are now one position, the “programmer analyst”, and it’s been that way for 20 years now. 

And what does a programmer analyst have to do? 

- examine and understand almost any business situation 

- solve technical and logistical problems 

- present ideas clearly and cleanly 

- organize and manage time and tasks 

- play nicely with others 

- and, oh yea, code 

And where do you find people who can do these things? Lots of places, but the 2 that come to mind first are from work experience or college experience. Nobody actually believes anymore that you’ll use anything from class in your work. But it can be a very good place to develop the life skills needed to be a programmer analyst. 

Nobody’s going to ask you to write a linear programming model using the simplex method to determine how to allocate continuous inventory to customer orders. (OK, maybe they will.) But they will wonder why Mary and Joe can’t seem to figure out how to use Program ORP560 to generate this month’s performance metrics.

Is the problem with them or the program? They’ll tell you to figure it out and fix it. Count on it. And count on college to help you become the kind of person who can do that. 

Here is the dirty little secret about evaluating the code you write in the interview: 

What is on the piece of paper (or editor) doesn’t make a whole lot of difference. 

What happens when you and I talk about what you wrote tells me almost everything I need to know. 

Less than one percent of interview code I’ve ever seen even compiled. What I was really looking for was: 

- Did he understand the problem? 

- How did he approach the problem? 

- Does he appear as if he has any idea what he’s doing? 

- Can he explain what he has done? 

- Can he defend what he has done? 

- Does he understand the concepts of order, cleanness, iteration, branching, recursion, etc., etc., etc… 

- Based on this small sample, do I think he can do the work we need done? 

- Do I like him? Will he fit in and be a good team member? 

So assuming they interview like I did (a big assumption), here’s the good news…whether or not you’ll do well has already been determined. So don’t bother to “cram” between now and Tuesday. Relax. And have fun. 

Be yourself and it will all work out OK (one way or the other). 

I know lots of online retailing millionaires. Is it easy? No. Is competition fierce? Of course. Are margins slim? Usually. But if you have passion for an idea, a market, a good plan, and are willing to work your butt off, then there are fantastic opportunities. 

(Aside: You won’t get a whole lot of response from people making their fortunes in on-line retailing in December - many of them are working 20 hour days this month.) 

I have often thought about starting something, but I’d rather hack. (I think that anyone can retail, but few can hack - I’m not so sure how empowering this thinking is.) 

Things you’d better consider before taking the plunge: 

- How will you find customers? Search engines, email blasts, catalogs, list buying, renting, or sharing, advertising… 

- How will you fulfill orders? Your own garage, rented space, dropshipping from your vendors,… 

- What capital will you require and where will you get it? (This may be the biggest barrier vs. hacking) 

- How much volume will you have to do to break even? (Better be right about this or you’re dead in a hurry) 

- What people will you require and how will you manage them? 

- What systems will you require and where will you get them? (Needless to say, there is great opportunity for competitive advantage here.) 

- What makes buying from you so much better than anyone else? (Maybe the most important question.) 

- There are hundreds of other things to consider, but you get the idea… 

People have started with a small idea are parlayed it into hundreds of thousands (and even millions) of dollars per year in less than a few years. The case studies are almost endless. Google a few and see how they did it.

Or watch Donny Deutch’s show “The Big Idea” on cable TV.

If you decide to do something like this (not the best time of year now since everyone will be tapped in a few weeks), find your niche and go for it. Best wishes.

Better to ask first. 

Problem is that systems analysis is a lost art. People don’t know HOW to ask. 

People know what they want. They just don’t know that they know. 

Here are just a few to the things you have to do (that almost no one does anymore) in order to elicit requirements: 

- Spend time with users doing what they do, asking questions until you understand how things work. If this means sitting at their desk, following them around their office/factory/route, or wading hip deep in , then DO IT. 

- Ask questions to groups of people at the same time, so they can argue with each other and learn together what’s really needed. 

- Ask lots of “Yes/No” questions. 

- Ask lots of “On a scale of 1 to 10…” questions. 

- Ask lots of “What is the probability that …” questions. 

- Cover the wall with paper and draw pictures of EVERYTHING. Leave the paper there for all to see for weeks. Let them understand and learn together. 

- Put every piece of paper they use in their jobs (or personal life) on the wall, so they (and others) can really see what they have to deal with on a daily basis. Not blank sheets, but paper with real data on it. 

- Identify every data element. How do you know when you’re done? Keep asking until there are no more answers. 

- Feed people while you ask them. (Amazing how smart people get while eating pizza.) 

- Then (and only then) give them a prototype to play with. (I suppose here is where your “measure” comes in to play.) 

- Exactly right? No? Keep going until it is. 

Aside from the prototype, we haven’t written a single line of code. Is this hard? Absolutely. Maybe that’s why most of us don’t do it anymore. Does it work? It you know what you’re doing: every time. 

(Aside: Notice I never mentioned using crap like Rational Rose or UML. That stuff was never meant to help this process. It was meant to make people who don’t know what they’re doing appear as if they did. Built an industry by paying junior people $50k and billing them out at $250/hour.) 

Single entry/single exit refers to ANY process, not just functions. Don’t underestimate the hell who can go through with poor variable naming. Case in point: 

2 months ago, a client needed significant changes to a major process in their app. (I had 2 weeks.) This process was a BASIC subroutine called by 16 other processes. Now get this: It was 2800 lines of code with one entry and 16 different exits. It was written in 1991 and had been modified 68 times before I came along. 

Here are a few of the variables: A, AA, AAA, AAAA, B, BB, BBB, BBBB, C, CC, CCC, CCCC, INFO, FORM1, FORM2, FORM3, HOLD.FORM2, OLD.FORM2, ORIG.FORM2, STUFF, DUMMY1, DUMMY2, 

DUMMY3… You get the idea. I spent 4 days renaming variables before I could start refactoring. There were some variables I never did figure out. I rewrote the program (550 lines) and hit the deadline. I uncovered over 20 undocumented bugs. I wonder what it will look like 5 years from now. 

Everything I write new is either Javascript or PHP. Now that my startup is ramping up, soon I won’t have to deal with any of this old stuff any more. 

(Aside: I wonder how much production code in the world today is over 10 years old. And how much has been modified over 10 times?) 

10. The exact same code is in multiple places because you didn’t bother to put in into a common function. 

9. You have error codes in functions, but never bother to look at them (a sure sign that testing was never finished). 

8. You have early exits from loops because you don’t know how to properly code a recursion. 

7. You execute too much code because you don’t know the difference between “if” and “case”. 

6. You use 10 lines of code when 1 line would do because you don’t know any better. 

5. You need to run batch jobs from time to time to clean up your data base because you don’t know how to debug well enough to find what’s messing it up. 

4. A third grader doesn’t know what your variable names mean. 

3. You think “Third Normal Form” is paperwork you need to fill out for one of your 8 bosses. 

2. No programmer who has to maintain your code would ever want to work with you. 

1. Any programmer that has to maintain your code would be more than happy to accept the consequences of first degree murder. 

Yes. Here’s why…

You get requirements from your daytime job.

This is so important that when I stopped moonlighting and went full time on my start-up, I kept an outside client 2 days per week. Let me explain…

One of my biggest problems has always been WHAT to build, not HOW to build it. Many successful start-ups have been the result of building what one needed oneself. I just expand “oneself” to include my parttime clients. Think you have needs? Wait til you see the long lists of needs in almost any small business. Sure, I lose a little time in the development cycle, but I more than make up for it at user acceptance time. No cycles there - I already know what they want.

Tell you why I don’t like syntax highlighting (or any crutch). Ever since I read the chapter about Woz in Founders at Work. The thing that he thought made him so successful designing the Apple II: he knew every single little part of it intimately, like the back of his hand. That struck me like a lightning bolt. So that’s how I feel about my code now.

If I want to do something, I read and reread and reread it over and over and over until I practically memorize it. THEN it’s part of MY firmware, and that’s when I really get insightful and productive. IDE’s, syntax highlighting, etc. are just crutches that keep my real “hacking muscles” from developing. I won’t use them. Black and green; that’s all I know.

Similarly: I used to know every phone number I ever needed by heart until speed dial came out. One day last year, I had the very frightening experience of not being able to call a regular number from someone else’s phone. I have never used speed dial since. Anything that impedes my “brain exercise” is something I do
without.

When it’s a house of cards. 

Perhaps I’m a little jaded, but I’ve built a very nice career rewriting software that never should have been written in the first place. Of the existing code I’ve encountered, at least 95% would never have passed a code review by me (or anyone else who knew what to look for). 

The problem is that we’re so committed to pass user acceptance testing that we never subject the source code and data base design to the same rigors. 

I like to think I’ve seen it all: one and two character variable names that mean nothing, homemade routines for sorting, selecting, you name it, memory leaks, iterations to nowhere, upward branches to nowhere, data base schemas that would make M. C. Escher jealous, and on and on and on. Face it, if programmers were doctors, we’d all be dead. 

As a constant victim of the “You Can’t Get There From Here Syndrome”, I often tell my clients the same thing, “It’s not how soon we get started, it’s how soon we finish AND how capable we are to handle the next revision”. 

Often rewriting is the last best hope. 

I got invited to an interview, what’ll I do? 

I got rejected, what’ll I do? 

PHP sucks. 

C# sucks. 

Microsoft sucks. 

Ruby rules! 

Best. Interface. Ever. 

Scientists in Sweden produce Britney Spears in a petri dish. 

pg is great. 

Where can I get the best corporate lawyer in the world for free? 

Anyone want to buy some legal drugs? 

Ask HN: When I sit too long in this chair, my back hurts. What should I do? HN: Switch chairs.

YC should start a franchise in Europe. 

YC should start a franchise in Latin America. 

YC should start a franchise in Asia. 

YC should start a franchise in Brooklyn. 

Ask HN: I don’t know how to code? How can I build a web app that makes a million dollars by Tuesday? 

Ask HN: I need motivation. Any hints? 

There. You just read all of today’s HN news. Now close your browser and get to work.