CRUD Jobs

If you’re not familiar with the term, ‘CRUD’ is an acronym for Create / Retrieve / Update / Delete, which are the basic database operations performed by a typical internal IT system. From that history the term has evolved into somewhat of a pejorative for boring, monotonous development jobs, typically involving applications with forms tied to databases with nothing much else interesting going on.

Of course, there are plenty of people happily doing CRUD work, so the stereotype is not always accurate. Still, the conventional wisdom is that CRUD work is not where you want to be if you are interested in leading edge technologies.

BTW, this contrast of CRUD vs. non-CRUD systems is analogous to my earlier cost center / profit center discussion, and it just so happens that most CRUD development is done in cost centers.

Unfortunately, the cold truth is that the vast majority of software work out there is done on CRUD systems. You see it everywhere – payroll, CRM, ERP, loan processing, etc. These types of applications far outnumber the more glamorous Google / Facebook type positions (although websites like Facebook could also be considered CRUD applications!).

Note also that some people use the term ‘IT’ or “Information Technology” to refer to CRUD jobs in general. However, I like to use the term IT as a broader description of the software engineering industry. So when some people put down IT as a dead-end function, make sure you understand what they’re referring to. Chances are they’re referring specifically to CRUD jobs in internal MIS departments (i.e., cost centers).

As a candidate you may have a choice between a seemingly stable CRUD job vs. a faster paced position at a software company or website. In these cases I’d generally recommend you choose the software company, all other things being equal. You’ll most likely learn more, have a more rewarding career path, and work with more challenging and leading edge technologies.

Working for a Cost Center vs. a Profit Center

Being an organizational profit center means the work you do generates revenues for the company. Conversely, being a cost center means you are costing the company money; i.e., you amount to overhead. So obviously it’s better to be thought of as a money maker than a money loser. Companies tend to invest heavily in profit centers, whereas they’re always trying to cut costs in a cost center, especially in an economic downturn.

So what kind of developer jobs will land you in a profit center? Typically, product development in a web or software company is associated with a profit center. To put it another way, if your company’s customers pay money to use what you are creating, or if your work generates revenues in some other way (e.g., advertising), then you are part of a profit center.

On the other hand, if you write systems that are used internally, whether by Accounting, Sales, or anyone else, you are most likely working in a cost center. It would behoove you to transfer to another department or to a new job that is associated with a profit center. Even if your internal customers are singing your praises, it may only take some downturn in business before the company decides to engage in belt tightening and the grim reaper visits your department with pink slips.

OOP and Programming Language Snobbery

I grill all candidates on Object-Oriented Programming skills even if they are purely front end developers. After all, ASP.NET does provide a separation between markup and logic (and also presentation, via CSS). Hence the logic portion in the C# codebehind needs to be written with proper object oriented design principles in mind.

Unfortunately some people who got their start in classic ASP have bad habits as they were accustomed to writing snippets of C# or VB.NET code directly within the ASP page markup. <% This is bad! %> They may have never needed to use O-O principles or design patterns, and hence never felt the need to develop such skills.

If candidates do not have direct experience with C#, I look for experience in C++ or Java -- languages with OO characteristics. That’s not to say that Smalltalk, Lisp, Pascal, etc. are not OO languages, but they are more academically oriented and less directly relevant to the kind of development we do. Even VB.NET, which is pretty darned close to C# nowadays, is often looked down upon, fairly or not.

Does it really matter whether a person has programmed in the O-O paradigm, or more specifically in a C++ style language? Or that they can properly describe a C# class, an interface, or a delegate? Perhaps some will see such questions as a trivia contest. However, it really does matter that developers know this stuff, so that they don’t make wrong decisions such as passing parameters by value instead of reference, making unnecessary copies of objects, calling components out of proc vs. in-proc, etc. These things do matter, and wrong design decisions have consequences.

Some people may also wonder whether this is a case of language snobbery. What’s wrong with a candidate having a background in something like VBScript, Python, or Perl, if those languages can get the job done? Why, nothing, of course. But the more (non-O-O) spaghetti code that’s created, the less maintainable the code base becomes. Plus, such an approach definitely does not scale. And maintainability and scalability are the key requirements of successful software engineering.

Generalist or Specialist?

Continuing on the topic of learning new technologies, should you learn as many skills as possible or should you specialize in a few? Which will make you more marketable?

In my world view there is no such thing as an IT handyman. Actually, come to think of it that’s not a bad analogy. If you are constructing a skyscraper would you want a team consisting of an architect, a general contractor, and skilled tradesmen – or would you hire a bunch of handymen? The obvious answer is that you’d want specialists who are experienced in their fields. There’s no way that a single person can be an expert architect, draftsman, mason, carpenter, plumber, electrician, etc., all in one, regardless of what they might like to believe.

The situation is not too different in the technology world. In fact, IT presents an even wider array of skills for people to learn and master. While it’s true that good engineers can pick up new technologies fairly quickly, it still takes years to become an expert at most of those skills. So when I see a resume from a candidate that claims expertise with ASP.NET, J2EE, LAMP, Ruby on Rails, C#, C++, VB.NET, PHP, Perl, Python, TCL, Flash, SQL Server, Oracle, etc. -- naturally I’m more than a bit skeptical.

My recommendation is to pick a single track and become as good as you can with that skillset. You can (and probably should) supplement those skills with other technologies, but when the rubber hits the road you need to show real competence in a particular area. The tracks might include:

Front End Web Development:

• ASP.NET / C#, or
• PHP, Python, or Perl, or
• Java / JSP / Struts / Spring MVC, or
• Ruby On Rails

Middleware / Data Services:

• C# / WCF / ADO.NET / SQL Server, or
• Java / Spring / Hibernate / Oracle, or
• MySQL + various ORMs

Infrastructure

• IIS / Windows Server, or
• Apache / Linux / Solaris

This is obviously not a complete list, and there are many possible technology combinations, but it does highlight a number of possible specialization tracks. Many of the tracks are complementary, but it’s unlikely most people could be experts in more than one or two of them.

You might be wondering, does this advice conflict with what I said earlier about learning lots of different technologies? Not at all; my philosophy remains the same -- you need breadth as well as depth. Show that you are familiar with a range of technologies, but pick an area of expertise and learn that set of technologies inside and out.

Following ‘Hot’ Technologies

To maximize your marketability, should you learn .NET or LAMP? Or Java? C# or VB.NET? PHP, Perl, or Python? Flash/Actionscript or Silverlight? Ruby on Rails? Or something else? What technologies will be hot a year or two from now? Or in five years?

There is no easy answer to this question. The marketplace is littered with corpses of technologies that were once considered ‘hot’ but which are now shunned. I’m thinking for example of (in no particular order) CGI, EJB (v1), MFC, TCL, etc. Going back further, you might remember such fallen stars as Delphi, PowerBuilder, and Sybase. Heck, if you go back far enough, I still remember when Turbo Pascal was considered hot stuff.

Even now there are technologies which were recently hot but which are on the wane. I’m thinking of things like Cold Fusion and classic ASP. There is still some demand for these skills, but I foresee that declining in the future as companies transition to other technologies.

Looking ahead though it’s impossible to see what technologies will ‘prevail’. Most likely there will be several technologies that thrive within their respective segments; there’s no reason that a single technology has to dominate everything.

Right now, I’d say that .NET, Java EE 5, and LAMP are all good choices for a career in web development, with the ‘P’ in LAMP being PHP, Python, or Perl. Internal IT departments seem to favor .NET and Java, while most startups lean towards PHP. Ruby on Rails is also becoming increasingly popular, though a lot of people remain skeptical about Ruby for large scale applications. Of course in five years the picture may be very different.

My advice? It’s similar to what I posted last time. Pick an area of specialty, whether it’ s.NET, Java, LAMP, or RoR, but read up and stay current on the other technologies. In this fast-moving technology world (and a fast-changing economy), you want to hedge your bets wherever possible.

Keeping Your Skills Up-To-Date

How do you keep current on the latest skills when you are not exposed to it in your day to day work? I suggest you get good books on new technologies and read them at work or home when you can. If you don’t have much free time you could read a chapter during lunch or other breaks.

It’s important that you keep up on new skills even if your job has you working on the same things every day. In fact, learning new things is especially important if you work with the same technologies every day, as your job won’t provide you with much learning opportunity.

To illustrate, let me recount my own story (Warning! Old fogey nostalgia alert!). Over the years I’ve had to learn a new set of skills and technologies every few years. The progression went something like this:

1. BASIC: This was ‘classic’ BASIC, not the ‘Visual’ kind, and certainly not VB.Net. This was how I learned to program back in my high school days, tinkering on an Atari 800. There was also a bit of 6502 Assembler thrown in for fun.
2. Pascal: I learned this in my first college programming class, using Sun UNIX workstations. Some old timers still remember when Turbo Pascal was the hottest language around for PC development.
3. C: I learned this in on the job, in fact in my first job out of school, reading Kernighan & Ritchie. We were still using Sun UNIX boxes at work.
4. Windows (3.x) development: Around 1990 I taught myself this using the original Petzold book, the bible of Windows programming. Back then we still had to worry about programs fitting into 64K in the small/tiny/medium memory models.
5. C++: In the early to mid 90’s I taught myself this language using books like Stroustrup’s ARM (not the best learning material, BTW).
6. Win32 API, MFC, Sockets, SQL, VB: I learned these standard tools for desktop & client-server development during the mid 90’s.
7. COM/OLE, STL, ATL – Thick books taught me these highlights(?) of traditional OO design and programming in the late ‘90s.
8. C# / .NET, ASP.NET, HTML, CSS, JavaScript – Re-tooling my skills for the web and .NET after 2001.
9. XML/XHTML, AJAX, WCF – The latest and greatest .NET stuff circa 2007. Also learning Java EE5 on the side.
   

I would consider each of these to be distinct generations (or epochs) of technologies. That means that I’ve gone through nine or so different generations of skills, and I’m most likely not done yet. In a few years I might have to learn a whole new set of technologies; perhaps it will be LAMP or Ruby on Rails, or it could be a new set of technologies that have yet to be invented.

The point here is that you need to constantly update your skills every few years as they will inevitably become outdated over time. Hence as a software engineer you can never really afford to stop learning, unless you want to exclude yourself from the jobs that demand the most current skills.

Considering a Position with a Startup

Earlier I discussed valuing stock options for a startup. Your mileage will vary, of course, but how exactly will it vary? Joining a startup may provide you with tremendous opportunities, but it could also leave you out on the street within a year. Hence you need to go in with your eyes open.

An early stage startup may have less than 10 employees and you may very well be one of the first technical people brought on board. You will likely get a pretty good stock option package but only a modest salary. The company at this point is probably running off on seed or angel funding, or possibly financed by the founders themselves -- so there’s not a lot of excess cash floating around. The company needs desperately to make the first version of its product work well enough to attract additional rounds of funding. And of course it goes without saying that you’ll be spending the vast majority of your waking hours chained to your desk.

Joining a startup at this point is undoubtedly a risky proposition, but it also offers the greatest potential reward. As the company grows you will likely benefit from several promotions, and if you have a successful exit you may be able to cash in your options for a healthy profit. On the other hand, it’s just as likely, if not more, that the company will wither on the vine or crash and burn spectacularly.

There are many reasons why an early stage startup can fail. A poor product is certainly one obvious reason, but it’s only one factor of many. Poor management is another common one, along with a lack of clear product vision, or a poor understanding of the market. And of course luck and timing also plays a factor. Woe to you if you launched your Internet startup in early 2001!

Hence when you interview with an early stage startup you should ask hard questions to the top management (whom you’ll definitely meet). Ask about their previous experience managing startups, the funding situation, the investors (both angels and VCs) and their connections, the board of advisors, etc.

With a later stage startup, the organization will likely have gone through a few rounds of financing and should have a product already in the marketplace. This type of company probably has 20-100 employees and is looking to bolster its engineering capacity to ramp up product development. They should also have a marketing and sales organization in place, or the beginnings of one.

With such a company you should be able to get a fairly decent sense of how well they are doing. When you interview the senior managers they should be willing to tell you outright whether the company is profitable. If they hem and haw, or say “that depends on how you define profitability”, that should raise red flags.

Still, a company at this stage has shown that they are capable of raising funding, and they should have a decent revenue stream, even if they are not exactly profitable. Hence just by virtue of the organizational inertia your risk of being laid off six months after starting is low. However, your chances of getting rich off stock options are low as well, since at this point they will most likely start getting stingy with their stock option grants.