ed weissman

Garbage Perpetuation Development (GPD) - You can’t believe how bad the existing code base is, but you’re afraid to open a can of worms, so everything you add to it is written in the same style. For the rest of your life, you can say, “It was like that when I got here.” 

Mansion in the Quicksand Development (MQD) - The opposite of Garbage Perpetuation Development, you are so shocked by the poor quality of the existing code that you vow that you’d rather swallow razor blades that code the same way. So you write a tight beautiful refactored masterpiece that will crash as soon as the underlying database loses its integrity (later tonight). 

Defer to the Framework Development (DFD) - You’re not sure how to tackle quite a few critical design/architecture issues, so you convince your boss to adopt the framework du jour and decide to “let it handle it”. As soon as someone needs something that the framework doesn’t handle, you blame management for making such a myoptic technology decision and say that it can’t be done. You keep your job and get a new boss every two years. 

Not Invented Here Development (NIHD) - The opposite of Defer to the Framework Development, as soon as you discover something the the current framework can’t handle, you abandon it and write all you own routines. Everything now works exactly as you want it, but with all the additional code to maintain, your backlog has just grown from 6 months to 2 years. 

Whoever Screams Loudest Development (WSLD) - Just as the name implies, you work for the customer who screams the loudest. If anyone screams louder, you drop everything and work on their project. 

F-Bomb Development (FBD) - Whenever everyone is screaming so loud you can’t hear anything, you work on the project of the customer who drops the most F Bombs. 

Start Over Development (SOD) - A critical requirement cannot be supported by the current architecture, so you decide to rewrite it. You spend 3 months designing the new architecture and then 6 months writing the new code. You never finish because you’re out of business. Now you know what “critical” means. 

Workaround Development (WAD) - The opposite of Start Over Development, you can make the current system do anything. You are so clever with your extra algorithms, functions, and data bases. Even with all your great variable naming and comments, six months later, you have no idea how anything works. 

Code Generation Development (CGD) - You’re so tired of writing the same code over and over, that you write a code generator to do it for you. What used to take a week only takes a few hours with the new tool. But you’re no further ahead because 80% of your time is needed to enhance and maintain the code generator. 

Infinite Prototyping Development (IPD) - Your customers and users are unable to describe or document their requirements. So you spend lots of time with them understanding their business and when you’re ready, you throw together a prototype. They love it, but it needs just a few changes. You keep making changes, but it always needs more. It stays a prototype forever. When the app crashes because of security or scaling issues, you’re off the hook because, “It’s only a prototype.” 

Infinite Analysis Development (IAD) - You never have to do anything because you never have specs. Woo hoo! 

Level 0: You don’t know that anything is wrong. You just think that’s just the way it is. 

Level 1: You know something is wrong, but you don’t know what to do about it, so you just go along with the program. 

Level 2: You know what to do about it, but aren’t yet able to do it. So you stick it out, learning as much as you can. 

Level 3: You know what to do about it and you are capable of doing it. Now you’re really pissed off (mainly at yourself) because you’re a fish out of water, in a place where you don’t belong. 

Level 4: You do something about it. You challenge the people at work to fix things. You start fixing them yourself. Or, best yet, you just go out and do it right on your own. Either way, sweet relief.

Get to Level 4. The days of pissedoffedness will soon seem like a distant memory.

(I have been through this cycle many times, but now I’m at Level 4 and have no intention of ever going back.) 

Buyers of software products, like small children, hear one word more than any other: “no”. “No, it can’t be done.” “No we don’t do that.” “No, if you did that it would screw up everything else.” “No, that’s stupid” It doesn’t matter if you’re right, all that matters is that you’re just another person saying “no”. 

You differentiate yourself from others by giving the exact same answer, but with the word “yes” instead of “no”.

“Yes, in order to do that, we’d also want to look at…” 

“Yes, let’s make it ‘pop’ using some of the things we bring to the table…” 

“Yes, no one even thought about that, and we should now before we get any further into this thing…” 

or even the extreme: 

“Yes, there’s a way to do that. No one has ever done that before, so now is the time for someone to be first…” 

As I’ve told my customers many times, “The answer is always ‘Yes’. You may not want to do it once you understand what it will take, but the answer is still ‘yes’.” 

No other word has helped me more to find myself and do my best work for others.

When I hire, I’m not looking for a person or a resource. I’m looking for a solution to my problem. Sometimes that problem is big, sometimes it’s urgent. But there’s always a problem needing to be solved. The more a candidate looks like a solution to my problem, the closer to the front of the pile he/she gets. 

As far as I’m concerned, the most important thing for any candidate to do is to identify my problem(s) and present themselves as the solution. The problem could be: 

-We just got a bunch of new business and need someone to do immediately to satisfy those customers.

-We just acquired another business and need to convert/integrate from technology to technology and need someone who knows both technologies (or either one) and has done that before. 

- We have a new business problem and one possible solution is to build/enhance/maintain an app. Can you do that? Have you done that? 

- We plan to grow x% over the next 24 months and we need people to do more of what we already do which is <x>. Can you do that? Have you done that? 

- We have a problem and frankly, we’re not sure what to do. What would you suggest? Can you do that? Have you done that before?

 You kinda get the picture. The tricky part for any candidate is the research. How do you find out what my problems are? Ask! Ask me. Ask someone else in the company. Ask anyone. The simple act of research shows that you’re a serious candidate. The follow up with a solution to my problem puts you at the top of my list. 

If you’re right out of school or don’t have a lot of experience, you should still do this. You may not have as long a resume as others, but you have every bit as much to offer to solve my problems. Maybe a smart person who works hard and knows how to deliver is just what I need. You must find that out and present yourself as such. Remember, it’s about my problem, not yours. 

This was I great question. I’ve never seen it before. The fact that you thought enough to ask is a “huge” first step. It shows that you’re thinking about me, not just yourself. Keep thinking like that and there’s no telling how far you’ll get. Thank you and good luck.

The longer I am a programmer, the more I realize that I love my job because of the actual work I do. Period.

I love the idea that people are trying to get things done, but need a little help from me to get them the tools they need. I love discovering with them what they need and how to get it to them. I love all that data sitting on disks somewhere begging to be used. I love all that data outside of any computer begging to be put on disk. I love the idea that I am master of a little universe that I can see in a 19” square right in front of me. I love manipulating important things, both complex and simple, with just little flicks of my fingers. And most of all, I love seeing something that came from nothing work for the first time. I did that! (Happy dance) Oddly, not much else matters…

I have worked in the most deploreable conditions at the most difficult times and hardly noticed when the work was good.

OTOH, I have worked in Class A office space with the nicest people and best conditions and was ready to jump out of the window from boredom or frustration.

Yes, the more I think about it the more I realize that it’s the “work” that matters. If it’s important enough and I’m allowed to do it, I don’t need much else. If it’s not, then there is no perfume could that make that pig smell good.

“Am I in the wrong major?”

Yes.

You (and some others) may not like what I’m about to say, but you asked for it, so here goes…

In all the years I’ve been in technology, it has typically taken me about 28 seconds to determine if another person was “fluent” more than one or two levels below the surface.

Those that were were almost always programmers, engineers, or technicians at one time or another. Everyone else was at best managers and business people, or at worst, administrators or posers.

I know some might disagree with me, but a Computer Science major who doesn’t want to code is like a dental student who doesn’t want to look into anyone’s mouth.

To get good in technology, and I mean really good, you must get under the hood, deeply and often. The best and most logical way to do this is by programming. And you will have to do this intensely and for long hours, so “you have to love it”.

The single biggest difference I’ve seen between great programmers and everyone else is a pure love for what they do. Intelligence matters, work habits matter, ability to work with other people matters, but make no mistake about it, there is no substitute for passion.

Great technologists love what they do so much, they can’t wait to get back to it. They have to check on their work after dinner. They have to review their notes at bed time. They are often the first in the office in the morning and just as often the last to leave. They read and learn voraciously and can’t wait to apply their skills to new problems. They’re so busy doing what they love, they don’t even think of it as “working 9 to 5”.

By your own description, you do not sound like this. So do yourself (and the rest of us) a favor and find something you love and major in that. If, on the other hand, it’s too late or it doesn’t make sense to switch majors, then go ahead and finish your CS major, but please find a direction to follow that puts you in work you love. Be forewarned, though. Unless you’re a programmer first, you probably won’t make a very good sales engineer or project manager. You may want to consider sales or even (dare I say) proceeding on to business school for your MBA.

I remember the time I took 4 enterprise vice presidents from New Jersey to visit a software vendor in Silicon Valley. They had great (multi-million dollar) software and it was perfect for this customer. 

Our first meeting was at 9 a.m., and there was no coffee! The Vice President of Sales actually found the coffee and filters and brewed the first pot himself in the vendor’s conference room. (Probably the first time he made coffee in 20 years.) Then he said, “Why should I trust them to handle my customer orders when they can’t even do the basics right?” 

A subtle but very important point. When engineering people sell to business people, we have the extra burden of showing that we know how to conduct business at their level. The easiest way to get started is with precise attention to details. And faux pas destroy trust much quicker with web technology. 

As a business programmer, I’ve worked on quite a few things where there is much more at stake than just money. Just a few of them:

- scheduling & routing of ambulances and firetrucks 

- scheduling & routing of trucks carrying time-sensitive medical supplies 

- clean-room quality control of medical devices 

- distribution of pharmeceutical formularies 

- medical claims processing & adjudication 

- formulas & recipes for large batch food processing 

- medical demographic databases of allergies 

- distribution of mission critical airline parts with linked certifications 

- certification of automotive safety devices, including airbags 

- building contractor specifications, including electrical & plumbing 

- clinic scheduling 

Just because something won’t hurt you immediately doesn’t mean that it can’t hurt you “eventually”. You can see from my examples that so much we program does affect the welfare of many, even if indirectly. 

We really have reached the point where software QA is just as important as engineering QA. We programmers aren’t the only link in the chain, but we are an important one. 

I have looked at horrendous enterprise code that supported critical health and safety issues and thought, “Do you really want to get on that plane?” or “Are you sure you want to take that pill?” (Hopefully QA catches most of the potential culprits.) 

Thanks for getting us to think about it a little more. This sort of thing should always be on any good developer’s mind. 

“One of the annoyances that we have to deal when building enterprise applications is the requirement that no data shall be lost.” 

Since when is a business requirement an “annoyance”? We keep data for lots of good reasons. Just a few off the top of my head:

- IRS requirements 

- SEC requirements 

- SOX requirements 

- data warehousing 

- data auditing 

- delayed undo 

- business intelligence 

- trend reporting & analysis 

- research & development 

- cooperative databases 

- industry databases & statistics 

“The usual response to that is to introduce a WasDeleted or an IsActive column in the database and implement deletes as an update that would set that flag.” 

Wrong. The usual response is archiving to disk using separate tables. This solves all of the requirements above while streamlining active database tables. It’s not unusual for 98% of all the enterprise data on disk to be in the archived state. 

“This sort of cleanup now has to moved up into the application layer.” 

So what? 

One of the biggest mistakes I consistently see is trying to use the facilities of a database management system to replace application logic. Indexes, triggers, and stored procedures are all critical tools in the developer’s arsenal, but they do not replace application analysis, design, and programming. Like security and scaling, archiving is a “architectural consideration”, not a bolt on. Including proper data archiving in the application’s design renders the hard vs. soft delete debate pointless.

The most important is the dedicated space with a door that closes. So you still “go to work”, just with a very short commute. A few other things that I have found helpful:

- When you're in your office, you're at work, working.
- When you're not in your office, you're at home, not working.
- Work in 48 minute bursts, then take a break.
- Only check email & voice mail during your 12 minutes off.
- Put internet and work on 2 different machines (if possible).
- I prefer radio over pre-recorded music; it reminds me I'm not alone.
- Eat lunch out with a friend several times per week.
- Eat home meals away from your office.
- If you're local, go in to the office once per week.
- If you're not local, go to the office several days per month.
- Dinner with SO every night, no matter what you're working on.
- A regular schedule of sleep, meals, exercise, and work makes things easier.