4 Things I Wish I Knew As A Junior Database Programmer

I started my career as a database programmer, doing support for several production systems. I was straight out of university and ready to take on the world of IT. Looking back now, there are a few things that I wish I knew back then that I know now, that I’d like to share with you.

What You Learn In Uni Isn’t Always Done In The Real World

In university (or college), you learn the theory behind software development and computer science. You learn how to program, you learn about algorithms, arrays, and abstraction. You get assignments to do, code to write, and books to read. You’re taught the methods that should be used to get the result you need in the real world.

When you get to the real world (a.k.a. “getting a job”), it’s a little different.

The biggest thing I noticed was that what I learnt in university wasn’t being done in the real world. Code wasn’t being written in the most ideal way (as discussed in the book Clean Code). Databases weren’t being designed properly – they weren’t even normalised. Systems were built in programming languages that were no longer being developed or taught.

I thought I could change all of that, but I couldn’t.

It took me time to realise that. There are many reasons that things are done differently than what is taught in uni. However, I’m glad I had the experience of uni and of starting in a job as a database programmer that was quite different, as it taught me there are many ways to get things done.

Evolving Systems Mean Evolving Code

In the assignments and classwork you get in university or college, you get a set of requirements and you go and build the solution, whether it is a document, a database, or a piece of software. You get the chance at the start to design it how it should be designed.

However, in the real world, in your job as a database programmer, this isn’t always the case. If you’re writing the first version, then yes, it can be straight-forward and you may get to design the database and the solution as best as you can.

In the world of business, software evolves. It goes through changes and updates. Software can be around for one, two, five, or ten or more years. Changes that are made to software are done within the constraints of time, quality and cost. This means they don’t always follow the initial design and can sometimes implement a less than perfect solution.

If a piece of software has been around for many years, as a lot of them are, you’ll find that it has had a lot of changes to it. Code has evolved and changed to a point where it’s almost unrecognisable from the original version.

Databases also change. While attempts were probably made to keep it in the same format, it would have evolved into something that is messy and not optimised.

This is another thing I wish I knew at the start of my database programmer career. Understanding that systems change and code will evolve into something different from a fresh, original version.

A Database Programmer Doesn’t Need To Memorise Code Syntax

One of the best parts about focusing on a particular area in university is that you get very familiar with it. I knew a lot of the functions and syntax for the programming languages that I studied, and so did my classmates, that by the end of it we were almost able to handwrite the code.

However important or unimportant that was in university, it isn’t all that valuable in the real world. I mean, knowing code syntax is important, but knowing it all off-by-heart isn’t required.

You can use the Internet and the API to research any syntax or function layouts that you need when you’re on the job. It’s usually pretty easy to do, with the amount of quality websites out there that explain functions. IDE’s these days, such as Eclipse, often give you syntax highlighting.

What I think is more important is learning what you’re trying to do with the code. Learning what functions are available and what you can do with the code and data as a database programmer is a helpful skill to know.

Early in my career I was focused on the syntax and the other details of the functionality, but over time, I learnt more about the functions and the best way to do things.

The Chosen Solution Isn’t Always The Most Effective

As I mentioned before, in the business world, software is implemented under the constraints of time, cost and quality.

This is known as the project management triangle. Basically, the project team is always prioritising two of these items, not three. For example, you can have time (a fast implementation) and quality (a good quality solution), but not cost (it will be expensive).

When I was in university, I always tried to submit the best work that I could. I would stay up late and get the assignment done so it would meet the criteria. Code would be commented, databases would be well-designed, assignments formatted.

I thought that’s how I needed to work as a database programmer when designing the solution.

However, because of the constraints of time, cost, and quality, you might be in a position where the choice of solution that is implemented isn’t the most effective one. Let’s say you have two ways of solving a problem:

Well-designed, easy to maintain, but more time and cost required

Average design (matches current system but not perfect), can be maintained by current team with some effort, less time required than option 1.

This depends on many factors, but most businesses will choose option 2. It would satisfy the requirements for the least cost. Of course, it depends on the company and where the project is at, but the point I’m making is that companies don’t always consider the best solution all of the time.

This was a big thing for me to learn. I couldn’t understand why project teams were choosing to force comma-delimited data into an existing table and processing it, rather than creating a new set of reference tables to use the existing and new data (for example). Eventually I learnt that there are other factors to consider and that it’s not always the IT team that make the decisions – it’s the people with the money.

I hope these points that I wish I learnt in my early roles as a database programmer will help you in your career. Do you have any other questions about being a database programmer? Share them in the area below.

Career Action Tip: Think about your current project or role, and try to create solutions that meet the cost, time, and quality constraints as best as you can.

Lastly, if you enjoy the information and career advice I’ve been providing, sign up to my newsletter below to stay up-to-date on my articles. You’ll also receive a fantastic bonus. Thanks!