Five Tech Support Horror Stories

The early years of my career were in tech support. As with any other job, there were good days and there were bad days. After the third year at the job, the bad days started to outnumber the good. It all seems hilarious in hindsight now, but there were some days where things in this list caused me to question my career choices.

Until one day it all came to a head and I decided I'd had enough, and started over in web development.

Sometimes I get together with some friends who are still in tech support, and we trade horror stories of the users we have to help. These are some of the stories that get 'em, every time.

1. Plugging in

This is actually a fairly common one, but let's start small. You get called to a user's desk because the desktop computer refused to turn on no matter how many times they pressed the On/Off button. And they even checked if the main switch was on. And judging from the light, it was.

Not plugged in.

However, upon closer examination, it turned out that the cord wasn't plugged in. Yes, you read that right - the power was on but the plug was just halfway into the socket and needed to penetrate another two inches before the computer could actually benefit from that power source.

Sound stupid? Welcome to my life at that time, buddy.

2. Opening Excel

Another alarmingly commonplace occurence was getting called into the office of some hotshot executive who was encountering an issue opening a MS PowerPoint file in his (or sometimes, her) MS Excel application.

Now, if you're still scratching your head and wondering why that's a problem, reread the preceding sentence. MS PowerPoint file. MS Excel application.

Just a bad fit.

I dunno, that was the early 2000s, and attempting stuff like that smacked of trying to fit a square peg in a round hole. It was amusing the first couple times, and then it got old real fast.

3. Infinite scroll

This was was so cartoonish it was almost amusing. I got a panicked call to a user's desk because her MS Excel spreadsheet was scrolling endlessly downwards on her screen and she couldn't understand why. It conjured up images of getting hacked, a malfunctioning monitor and whatnot.

The truth was even funnier.

Held down the ENTER key.

I got there, and the first thing I did was remove the heavy binder from her keyboard, which had been pressing down on the ENTER key and causing MS Excel to react as though some user was holding down that key.

4. Email Signature

This particular incident did not happen during my years of Desktop Support, but rather during my fledgling years as a web developer. However, the incident in question made me more determined than ever to never get back to Desktop Support.

A user had asked me to help set up her email signature because she had no clue how to use MS Outlook. I obliged, because I know sometimes Microsoft software functionality can be hidden in the darnedest places. But then after I got into the interface, input the standard company email signature template, I asked her to type in her name into the box and click the SAVE button.

Yay! We're now
qualified to type
our own names!

Guess what she told me?

"You should do it. You have an IT Degree."

That level of entitlement was staggering. What was she implying now, that she needed an IT Degree to type in her own goddamn name? What foolishness was this? This wasn't a competence issue. This was an attitude issue. And the less of this I see in the workplace, the better. There's no place for this nonsense in any work environment. Hopefully this woman has since retired. At the very least, she's someone else's problem.

5. Emails

This is also a fairly common complaint among grunts, not just tech grunts - people feeling like they're entitled to your time outside of office hours.

I remember having a dinner appointment with someone, and Human Resources asking me to stay back because they needed me to, wait for it, retrieve some emails from the email server backups between three of the staff. Staff they were planning to terminate, thus they needed evidence of wrongdoing as leverage.

A whole bunch of
DVD backups.

Basically, nothing was on fire. They just needed me to help cover their asses. Hours later, as I was retrieving yet another batch (back then, it was the era where stuff like that was stored on DVDs), when HR asked me: "I'm sorry, did you have something on tonight?"

Seriously, lady, if the answer was "yes" would it have made a difference? If not, how about just shutting the fuck up? You know what's worse than people who don't care? People who don't care and try to act (badly) like they do.

Phew!

I wouldn't say any one incident turned me off of Desktop Support. Even on its own, it can be a repetitive grind that wears on the soul. But these were the war stories that I shared with the guys. And their reactions suggested that these occurrences weren't at all unheard of. Some of their stories were even more unbelievable than mine.

No, you don't need an IT Degree to read this,
T___T

Ten Professional Hazards Of Writing Code For A Living

Human beings are creatures of habit. Any profession which entails long sustained periods of doing things or thinking a certain way, will have an influence on its practitioners. Years of being a programmer have changed me. In all fairness, some of these traits already existed way before I wrote my first Hello World program, though they were certainly magnified after that.

Here are some of the ways my job as a software developer have shaped me as a person. Some of these may make me look like an utter moron. I assure you that I am of at least average intelligence. It's just the job.

1. Counting from zero

Probably the most stereotypical quirk ever. "Programmers tend to count from zero". Yeah, right. The stereotype exists because in almost all programming languages, counting does begin from zero.

Do I count from zero? No, that's silly. I don't, for instance, look at a cluster of five apples and tell you there are four. Any programmers who do, I suspect, are just trying too hard for geek cred.

There are five apples, not four.

However, it does happen if I'm looking at rows of data. If I see an MS Excel worksheet with data all the way to number 100, I am going to think there are 101 rows of data. It could be because spreadsheets are usually the way I visualize arrays in my head (especially two-dimensional arrays) so my brain subconsciously thinks of spreadsheets as arrays.

Thus, while this stereotype is way overblown, there's some truth to it.

2. Being easily startled

When deep in the throes of writing code, programmers tend to concentrate really hard. I am no exception. There have been plenty of times when my brain is on a one-track highway through some programming logic when someone interrupts me by speaking in my ear or tapping me on the shoulder.

Violently startled.

And sometimes, my reaction can be... absurdly violent. Spilled coffee, sudden jumps, things like that.

This doesn't happen all that much these days. For one, I work from home. Very few people get to interrupt me. And even if they do, the fact is, I simply don't concentrate as hard as I used to.

3. Being very literal

One of the hallmarks of writing code is being drawn into the true or false dichotomy. Thus, there's this tendency to interpret everything as a "yes" or "no" question. To be fair, sometimes the question is literally phrased this way. But that's only as a manner of speaking; often, the asker means to ask a bigger question.

No capacity for nuance.

And because of this tendency, I tend to miss it.

I remember being at an interview where the hiring manager asked me if I knew how the PayPal IPN works. To me, the answer was obvious. Yes, I do. It was only after an awkward pause, and the interviewer rephrased his question, that I understood that he actually expected me to demonstrate how it works.

There were other interviews where I was asked similar questions where I simply said "Yes" or "No". But honestly, I also feel that if you're going to ask a programmer questions like that, you should also be prepared for replies like that.

4. Single-mindedness

This next one does not apply to all techs or even all programmers. But there's a fair number of programmers who tend to take a very insular view when writing code. This can be useful when you're writing a single-use method; as small as possible. Not so much if you're trying to design an entire system.

Laser focus... or just
tunnel vision.

And in real life, that can have negative consequences too. I've gotten into trouble with the wife for doing the correct thing... at the wrong time, or under the wrong conditions. Because the correct thing, in isolation, is the correct thing. But few things in life exist in isolation.

You don't want to wash the windows when it's raining. Or flush the toilet before taking a piss. All this is putting the cart before the horse, which can happen when you consider only the task at hand and fail to take the larger context into account.

5. Overusing techspeak

Tech work comes with a whole lot of terminology, some of which we're sometimes guilty of assuming that non-techies understand. After all, techspeak has become increasingly mainstream over the last decade as technology has become more entrenched with the general public.

This does not automatically mean that everyone knows what SSL is (despite a staggering majority of websites employing it). Or that a gateway doesn't always mean that entrance to a building enclosure. Or that when we refer to something as a "string literal", we actually just (kind of) mean "text".

No, not that kind of string.

And yes, I'm just as guilty as other tech geeks.

We're not trying to sound smart when we break out the tech jargon, cross my heart. Mostly because we are smart, and know it. No, it's largely because our work practically demands that we speak in what could almost be a different language.

6. Expecting output

As mentioned before, I tend to interpret things very literally. However, this also applies in reverse.

As a consequence of writing functions which expect very specific data type values in a very specific order, as input, and produce output which is also of a very specific data type, what happens is that this has a tendency to manifest when I ask questions of other people: I tend to expect a certain output and only that output. And when I ask for A, and people give me B, C and D in addition to A, I tend to get annoyed.

A lot of irrelevant information.

It's human nature; people want to be helpful. But what usually ends up happening is that they give you a lot of information that has nothing to do with what you wanted in the first place.

7. Cynical

Expecting the worst, or not believing it when things go well, is something ingrained in developers who do a lot of testing, which, let's face it, is pretty much all devs at this point.

Does your code ever run perfectly the first time? And when it did, were you happy or wary?

Glass is always half-empty.

Unless it's something really simple that would have been expected to go right, sometimes when things go too smoothly, I get worried.

My time running code has taught me that when no warnings or errors are reported, it's rarely because I did everything right, especially if it's the first run. No, there are probably bugs and gotchas, and they're well-hidden!

8. The How 

One more quirk of being a web developer is that one of the first questions we tend to ask is the How question. It's a professional hazard that may be shared by engineers in general.

Even when I'm asking something like "why did I get an error 500 on this API endpoint call?" it usually gets formattered as "how the hell did I get an error 500 on this API endpoint call?"

Examining how things work.

That's relevant, I promise. Because even in my early days as a web developer, I was curious about how things worked. I would find stuff on the web, wonder how it was done, and then I would make my own, just to prove I could. This also applies to other things in my life, non-tech related. I'd look at something, figure out the how, and make my own. I'm not sure if I'm this way because I was a web dev, or I became a web dev because I'm this way.

9. Lack of sympathy

I've been accused of having a less than exemplary bedside manner when people complain about their shitty careers or lack of opportunities in the job market. I've also been less than impressed with people who claim to envy the fact that I work in tech.

Heart of stone.

Really? Do people want to potentially spend days sifting through code, making changes that may end up creating problems bigger than the one they're trying to solve? Would they enjoy having to constantly remind their less tech-savvy colleagues that software development is not witchcraft and still has to conform to logic? Do they want to go through the slog I did, in order to get where I am now?

I know I don't. I simply happen to enjoy writing code enough to not overly mind that rest of the bullshit I have to put up with. People want the perceived better pay and job security of tech, but the job itself would drive them nuts.

And I have no sympathy precisely because I know I'm not better than the average schmuck. In the sense that, the moment I'm of no use, I'll be put out to pasture like anyone else. Look at the mass layoffs happening in Big Tech if you're not convinced. Job security? What a joke, right?

10. Flowcharting

Agile practices include making use of a Kanban Board system. The use of said system is good for training an organized mind, and lends into the software development practice of breaking up a huge problem into smaller, more manageable tasks.

The good old
divide-and-conquer.

And this has translated over to my daily life, to things like chores and personal projects. Even long-term goals like language learning. Everything is obsessively broken up into smaller sub-components, then managed.

The wife thinks I'm certifiably insane. She doesn't understand why mopping the kitchen floor and mopping the living room floor are two separate tasks, and have to be scheduled. Honey, I'm just a software dev. It's who I am.

What a hazardous list!

Are you a programmer by trade, and if so, how many of these apply to you?

How many apples do you see?
T___T

Software Review: Power BI

Forays into Data Visualization as an integral part of Data Analytics, have brought me in contact with several Data Visualization tools. One of these is Microsoft's offering, PowerBI. The "BI" part of the name, of course, stands for Business Intelligence, which is one of the use cases for Data Analytics.

If you have a need for ETL that will ultimately factor into your Business Intelligence, this is what PowerBI is for. Of course, PowerBI is not just about Business Intelligence. Any use case you may have involving transformation and visualization of data, will be handled by PowerBI.

The Premise

PowerBI is a desktop (or cloud-based, depending on your package) application that takes a data source or several, and combines them into a slick narrative, cumulating in charts, dashboards and storyboards.

The Aesthetics

Power BI follows a similar aesthetic to most Microsoft products. This means that if you're familiar with Access, SQL Server or Excel, you will feel pretty much at home right off the bat, whether it's managing dataset relationships or cleaning data.

Outside of data visualization colors, white and grey are predominant with button mostly in yellow. There's the occasional flash of green.

The Experience

Honestly, I found Power BI intimidating. Just for the simple task of importing datasets, there was a whole host of options to choose from. Further into the actual cleaning and visualization of data, each task had a blinding array of configuration options.

Thankfully, Power BI manages to stick to a well-established workflow - import data, clean and merge, create analytics, visualize.

The Interface

While the interface can get a little crowded, much of it is safely ignored with little consequence. For the most part, controls are straightforward and easy to find especially if you have had prior experience with Microsoft products.

Of special mention is the relationship relation interface. For such a busy looking display, the process of merging various datasets was relatively direct. And it was not clumsy.

What I liked

The meat of the software, as far as I'm concerned, is in the visualization. On that score, I wasn't disappointed. There are tons of chart types and dashboard options, with each chart highly customizable.

Simple things are easy enough to accomplish if you don't get distracted by all the other interface elements.

Statistical information about the data is available right off the bat when you view it, with more options available if you want it.

I've mentioned this before but it's great that the UI is mostly consistent with other Microsoft products.

What I didn't

Power BI Desktop is free. The costs of Pro or Premium seem a little high, though perhaps this can be justified with scaled-up use cases.

I found the going slow at times. This may be improved with the Pro or Premium versions, and may just be a result of me running Power BI on my ridiculously old Windows machine. Use on a Macbook was a no-go last I checked.

The screen can sometimes get a little crowded with the sheer amount of controls provided. Half of which I will probably never use.

Conclusion

PowerBI isn't what I would call a slick little package. It has a whole host of functions and sometimes all that can be overwhelming. Still, it's good enough for most cases even if the functions I really need are sometimes annoyingly elusive, hidden amongst a ton of related functionality.

I would absolutely recommend PowerBI for your Business Intelligence use cases. And if you can afford it, PowerBI Premium or PowerBI Pro.

My Rating

7 / 10

Powerful stuff!
T___T

Actual Requirements For Tech Expertise

Companies say they need tech experts. And I have no doubt that this is what they truly think. They write all sorts of fancy job descriptions that sound deliciously complex, only for you to realize, during the interview - or worse, during the first week at work - that their needs are far more basic.

What causes this phenomenon? I submit that this is largely found outside of the tech sector. Companies dealing in food, logistics, healthcare and the like, that find themselves in the position of having to undergo some kind of digital transformation.

In other words, get with the times. Keep up with the Joneses. Move with the world before it moves on without you.

This is what I think is happening. Companies that are largely traditional (with very traditional salary ranges) are finding, to their consternation, that the average techie earns significantly more than their average senior executive - even those techies that don't get hired by banks or Big Tech. In order to hire your run-of-the-mill tech grunt in-house, they'd have to fork out amounts they're not accustomed to.

So what do they do? They raise the price a little more, and ask for a tech expert. After all, if they're going to pay that kind of money, they might as well make it worth the price, eh? That's consumer mentality for you. No, I'm not mocking these companies. Not exactly. That's a perfectly reasonable line of thought if your business is outside of the tech sector.

Hiring the cream of the crop.

But the uncomfortable truth is, these companies don't need experts. They don't need geniuses who can invert a binary tree on the spot, or wax lyrical about recursion. They don't need database specialists who can perform Relational Algebra, or extremely experienced rock-star devs who can name you all the best working practices in tech, in the last decade.

And even in the extremely unlikely scenario that they did need someone like that, chances are such a prodigy would prefer to be climbing the ranks within the tech sector itself, not outside of it.

You see, the main obstacle isn't money, or even the willingness to spend it. The obstacles are both cultural and structural.

Companies that are used to doing things the low-tech way are going to have to get used to doing things at a higher level. It's not just a matter of hiring the tech expert; the company, as a collective whole, needs to up their game. And that is the main sticking point. Techies within the tech industry are used to having their methods accepted. They're certainly rarely in the position where they actually have to justify the merits of technology to their bosses, or aggressively push new ways of doing things. Because in the tech sector, change is practically a way of life.

Outside of the tech sector? Not so much.

Case in point...

An ex-colleague was recently showing me the advances that the company had made in technology. Instead of using a physical punch-card system, now they use a biometric facial recognition system.

As outdated as this machine.

Oh, wow.

Using advanced technology to carry out the antiquated practice of clocking in and out of your workplace, as opposed to using an equally antiquated method of doing so? The technology had changed; the culture hadn't.

I mean, what's the difference here? Whether you're killing trees for paper or merely consuming bandwidth and electricity, you're still satisfying HR's need to have everybody conform to the same work timings. It's still a pig; you're merely putting lipstick on it.

What do these companies need, if not an expert?

Well, just to be clear, I'm not saying that experts aren't useful. I'm saying that were they to be hired by these companies, they would be criminally underused. And that's not the company's fault, exactly. After all, if you're not a tech company and therefore are not accustomed to the way tech companies do things, then a reckless wholesale overhaul of processes has the potential to be a disaster of horrendous proportions. Tech companies do things a certain way because it makes sense to do them a certain way. Other companies, within their own industries, have practices that are a requirement of industry-specific standards. Copying blindly helps absolutely nobody. Useful practices can and should be adopted; the trick is figuring which practices are useful.

But for a start, hiring experts when you have no real need to, and probably can't afford to give them the time and autonomy required for them to make a real difference, simply isn't ideal. Companies convince themselves that they need experts, but that's only because they don't fully grasp just what technology is capable of, and what those experts could accomplish as opposed to the relatively basic nature of the company's operations.

Really, do you need experts to set up a biometric facial recognition system for the purpose of making sure your employees clock in and out on time? That seems extraordinarily petty.

So what do companies actually need to bring up the next technological rung? Well, for starters, someone more well-versed in technology than the average employee would do. And if we're going to be honest, that might not actually mean an expert.

To a layperson, tech
is like witchcraft.

Simply put, some companies are at a technological level where the concept of MS Excel pivot tables is a cause for a Wow response. The tech expert, at this point, is the modern-day equivalent of Hank Morgan appearing to ignorant Englishmen as a powerful sorcerer. What techies do (even the experts) isn't magic, but if you're sufficiently backward in mindset and technology, it may as well be.

A Story

Last year, I was hired by an organization on the recommendation of one of my ex-bosses. He told the Director that what the organization needed at this point wasn't a specialist or an expert, but a generalist. I wasn't sure what this meant at the time, but it wouldn't take me long to find out.

Out of the blue, an issue came up. Apparently, the employees operating the end-of-day sales report module at all the outlets were having trouble opening the report, which was in MS Excel format. They did not want to use the Office 365 web-based interface to open the report, as this would require one extra step, and worse, would actually require them to learn something new. As MS Excel licenses were in short supply, the Infrastructure Manager proposed that I rewrite the report in PDF format (which would open in any browser) while he installed Adobe Acrobat Reader on all the machines, and trained the personnel to use it.

Just use tables.

I did him one better. They just needed the damn report to open up right away without any extra steps? All they needed were HTML tables. Even if they were using bloody Internet Explorer, it would still work. The Infrastructure Manager wouldn't have to go through the nightmarish task of installing software on all machines at all outlets across the island, and no extra training was required.

They thought it would take a week, or at least a few days. I took all of twenty minutes to write the code, and presented it in the morning. The outlet staff were satisfied, and the Infrastructure Manager was off the hook.

Duplicitous of me? Very. But at one fell swoop, I had scored a few goals. One; I'd met the objectives of the outlet staff in a way that inconvenienced them the least. Two; I had saved the Infrastructure Manager a shit-ton of labor.

But I digress; the point of this wasn't to tell you what a sneaky SOB I can be, but rather to illustrate that this would not have been possible had I been a tech expert. A tech expert would have found it unacceptable that staff weren't willing to pick up new technologies (and bear in mind that at this point, cloud-based software isn't exactly new) and refused to enable it. No, I was a run-of-the-mill techie with a healthy respect for best practices in tech, but also a willingness to disregard them when the situation called for it.

The fact that I had years of experience in Desktop Support and already learned (the hard way) about people who refuse to learn new ways of doing things, certainly didn't hurt.

In Summary

For companies outside of the tech sector, hiring tech experts is difficult, and in some cases, sub-optimal. Context is everything. Hiring has to be done in accordance to actual needs and not a wish-list.

Your non-expert,
T___T

Software Review: Tableau Desktop

During an ongoing foray into the world of Data Analysis, I was introduced to a Data Visualization Tool known as Tableau Desktop. Prior to that, my experience with Data Visualization had been limited to less sophisticated means - via the use of libraries such as D3; or worse, writing code without using libraries.

Tableau takes care of all the scaffolding required to produce passably decent-looking visualizations, and more.

It was picked up by Salesforce in 2019, and this bodes well for its longevity. Today, I'd like to provide a quick overview of what makes Tableau so attractive to a developer; or actually, just about anyone who needs a fuss-free way to analyze data beautifully.

The Premise

Tableau Desktop is used to manipulate one or more datasets, possibly joining them into a coherent whole, then using that data to create charts of several different types. From there, charts can be placed into dashboards, and in turn these dashboards can be used to form a Data Story.

Dashboard and Data Stories

More intricate work such as interactivity can be added via Actions. Some of the cool things you can do using Actions are - redirect to another dashboard, open a URL, change data filters on an existing sheet, and more!

Actions

Data may also be manipulated using built-in functions provided by Tableau.

Built-in functions

The Aesthetics

Tableau's color scheme, for the most part, is a very black and grey on a white background. That works for a clean look. Other colors come in once the charts are being created. By default, it's mostly a muted blue, but this can be customized.

A clean aesthetic.

The Experience

It's fairly intuitive most of the time. Emphasis on "most". For simple charts, it's easy as pie (heh heh). For the more complicated chart types, the process becomes exponentially more complex. Perhaps it's just me, but trial and error reap little reward as opposed to consulting online documentation. Thankfully, the online documentation and tutorials are plentiful.

Response is fast, but in all honesty, the datasets I was working with were fairly limited.

The Interface

The majority of the controls on a drag-and-drop basis, with other functionality available via right-clicks and double-clicks. Options from the main menu duplicate this functionality in case the user prefers that route.

Sometimes there may be a bit of coding, and the interface allows for it. But there is plenty that can still be done without writing a single line of code. Most of the time, code is only involved when you want to do things like custom calculated fields and dashboard interactivity.

Code interface

Additional levels of detail are available in menus upon right-clicking. There's a lot that is customizable.

Many customizations

What I liked

Fast and responsive. I may have mentioned it before, but seeing data sort itself neatly into charts of various shapes without having to do much beyond drag and drop, is a beauty to behold.

Almost effortless. Tableau saves you the trouble of having to painstakingly set up data visualization, by taking care of most of the hard work. All that's really left for the user is to customize the look and feel... and even then it's not a lot of work because the default setting already looks pretty decent.

Huge variety of chart types. There are so many basic chart types, and variations on them. And quite a few I didn't even know existed.

Treemap

Bubble Chart

Dual-axis Chart

Pie Chart

Filled Area Plot

Grouped Bar Chart

Line Chart

Stacked Bar Chart

And while I might not use it much, I'd like to take a moment to gush about geographical data. Tableau has all that covered. If you define data as Geographical, it gives you visual representation on an actual map.

Geographical data

Country names

And if you further break it down into county level, it actually has updated information on that as well! This is what it looks like for Singapore! Awesome, right?!

County names

The different screen layout options for dashboards is a really nice touch. Tableau does have a nose for the essentials.

Layout for screen sizes

Online resources are vast. There will be times when you need help from more experienced users. It's out there, in spades. The official documentation, on its own, is already pretty comprehensive.

What I didn't

Tableau can be complicated. While the interface is pretty intuitive and most basic uses cases can be resolved with relative ease, beyond that, there are times where things get tricky. Putting together something like a stacked bar chart, for example, can be a matter of a ridiculous amount of trial and error. Thankfully, for such scenarios, the extensive online documentation covers it more often than not.

Tableau would really benefit from an "Idiot Mode" - some step-by-step interface where the user chooses the visualization required and the software provides a guide as to what to drag/drop, and where.

Conclusion

There are probably many Data Visualization software packages out there which I haven't had the pleasure of using (unless one counts Microsoft's Excel or Google Charts), so do bear in mind that my frame of reference is woefully limited. However, having had the experience of having to create visualizations without the use of such a tool, my experience with Tableau Desktop has been overwhelmingly positive.

My Rating

8.5 / 10

Give it a go; it'll bleau your mind!
T___T

So you want to be a Web Developer? (Part 3/4)

So we've covered the front-end and back-end aspects of web development. And, as mentioned in the last segment, we're going to delve into databases.

Unless you're only planning to create static websites, which in this day and age isn't really feasible as a career choice, at some point or other you're going to have to deal with databases, or at least a data source. Some databases are more suitable than others - it all really depends on the scale of what you're trying to accomplish. An enterprise-level application might require SQLServer, whereas MS Access is probably better for a simple disposable solution.

Again, as with back-end scripting languages, learn one database platform, preferably two.

- MySQL (http://www.mysql.com/)
- SQLServer (http://www.microsoft.com/en-us/server-cloud/products/sql-server/)
- MS Access (https://products.office.com/en-SG/access)
- DB2 (http://www-01.ibm.com/software/data/db2/)
- Oracle (http://www.oracle.com/index.html)

 

What you must know

- SQL (well, duh)
- Views
- Indexing
- Stored Procedures
- Database security
- Normalization

Good-to-haves

The following aren't absolutely necessary, but if databases are going to be your specialty, you could do worse!

Do have a look at CSV, JSON and XML as alternative modes of data storage and transfer.

MS Excel is a spreadsheet application, but through the years it's picked up a heft amount of added functionality. Worth a gander. (https://products.office.com/en-us/excel)

LinQ is an alternative to SQL. (https://msdn.microsoft.com/en-sg/library/bb397926.aspx)

NoSQL databases such as MongoDB and Redis. They seem to be the in-thing now. For a more comprehensive listing of NoSQL databases, see this link (http://en.wikipedia.org/wiki/NoSQL).

What are my career options?

If you're going to do only databases, why go into web development at all? There's demand for database administrators all around.

Next

Coming up, the final ingredient needed to be a web developer. Stay tuned!