Describing a “typical” day for an SQL developer is not easy. When your daily work is using various technologies to create interesting database-oriented products, very few days are alike! Each day brings a new and intriguing challenge.
Nevertheless, I’ll have a go at explaining what everyday things an SQL developer might do.
Morning: Arrive at Work
The cornerstone of any software engineering endeavor is caffeine, and lots of it. An industry joke is that programmers are “machines for turning coffee into code”. So I would say that most software professionals start their day with a nice big mug o’ joe. Some arrive early, others roll in a bit later, but all stave off sleepiness with the same brewed stimulant.
After saying hello to your colleagues, you sit down at your desk and start working. Now what you start is an interesting question. Usually, SQL developers either work on a database model or with some SQL code. Let’s look at each option.
If you are in a more modeling-oriented career, you will start your modeling software, possibly Vertabelo, and embark on drawing entities, thinking about normal forms and primary keys, and doing the whole modeling shebang.
More often than not, modeling is a collaborative process. You’ll bounce ideas around with fellow data modelers, talk with business analysts about the model’s requirements, or even discuss the business processes you are working on with business owners.
If you are more of a programmer, you will sit down and write code. Every enterprise-level database has some sort of procedural extension of SQL. Oracle has PL/SQL, Microsoft SQL Server has T-SQL, PostgreSQL has Pl/pgSQL, etc. These allow developers to treat SQL more like a “regular” or procedural 3G programming language, adding in elements like exceptions and loops.
Writing code like this is a balancing act between pure SQL statements and 3G executions. If you are a BI person (like myself) you will write more SQL statements, which churn out lots of entity data. If you are working on a transactional system, you will write more procedural code.
The difference between BI’s purer SQL and transactional procedural coding is a bit like driving along a highway. In a transactional system, the highway is filled with lots of small, fast-moving cars. The cars all look the same. They are all the same brand and they travel at roughly the same speed. In a BI system, the highway is sparsely populated with a weird assortment of vehicles that cruise along at different speeds. Some are slow-moving 18-wheel trucks, some are small city cars which buzz past, and some are just normal sedans. They all run at different speeds and usually they do not repeat themselves. Obviously, such very different traffic patterns require different approaches!
I find that, no matter if you’re doing modeling or coding, It is important to do your mental “heavy lifting” in the morning, when focus is at its peak.
You will reserve lunchtime for a highly important activity: bonding with your coworkers. It is important to nurture good relationships with your coworkers – remember, the product is only as strong as the team that built it.
Working in a dysfunctional team is a nightmare you don’t want to find yourself in. A positive working environment depends on everyone, so put effort into making it work! You may even make some lifelong friends.
Afternoon: Communication and More Work
It is a common belief that knowledge workers require two different types of workplace (or mindsets): a cave and a forum. The cave is where you do your mental work in isolation. Communication is minimal, and focus reigns. The forum is where you actively collaborate with your fellow workers.
Caves and forums are not so tightly separated that they can’t intermingle during the day. In the morning, you usually go into your cave, although this depends on what you’re doing (modeling or coding). In the afternoon, you join the forum. Some employers even physically partition workspaces to create specific environments for concentration and communication.
For me, the afternoon is reserved for administrative tasks and business communication, like reporting the status of your current project. This usually is in the form of a short daily meeting.
If you are in an administrative role, such as team lead, after lunch is the time to talk to your coworkers about their task statuses and problems.
With your communication done, your time sheet filled, and your code or design finished for the day, you head home.
I usually reserve a part of my evening for broadening my professional horizons. Some organizations set aside workday time for educating their employees, which I am a fan of. However, I also believe that self-education is a big part of becoming a serious software professional. As an SQL developer, you will have to continually invest your time in learning new and interesting aspects of your craft. This is one of the best things about software engineering!
The database field is continually growing, with new niches and opportunities appearing frequently. I keep up by reading various SQL-related blogs. I also read books to improve my skills. Sometimes I will code something or try out a feature in Vertabelo’s SQL Academy. Perhaps I will spin up a database on my own and fiddle with the database’s settings to test my code in variety of environments.
Data is growing at an ever-increasing rate and SQL is still the top method for working with it. If you choose the career of an SQL developer, I am sure that you will find it intellectually and financially profitable. So come and join us!