jump to navigation

Friday Philosophy – Are Good IT People Just Lucky Starters? April 22, 2022

Posted by mwidlake in database design, Friday Philosophy.
Tags: ,
trackback

There is a tradition in IT that older members of the community complain that “the youngsters of today” don’t really understand how to design systems, develop code, and test applications properly. It was like this in the late 80’s when I started. It was a common theme of discussion at the end of the 90’s. The 2000’s seemed to me to be endless carping about development frameworks that simplified things to the lowest common (poorly performing) denominators. And it seems to be a big part of what us oldies do on the likes of twitter or at conferences now – or at least did when we had proper conferences pre-plague.

One aspect of IT certainly has changed over the decades and that has been a shift in the layer(s) where most professional IT people need to concentrate to get the best out of a system. Back in the late 80’s the oldsters were saying you had to understand registers, memory pointers, the physical constraints of the hardware to get decent performance, and use a low-level programming language like C or even assembler. As time has gone on the move has been up the technology stack, leaving the lower levels like memory management and how interpreters work as either solved or looked after by a tiny set of people.

By the end of the 90’s it was all Middleware and application servers took most systems and thus development off the database servers or mainframes. software architecture and frameworks were supposed to remove the need to worry about *how* the data was got, and more modern languages meant you did not have to worry about memory maintenance, freeing resources etc.

One thing that has not changed (IMHO) but is now often overlooked is the physical placement of data, data structures, and how the storage works. I can often vastly improve the performance of applications or specific pieces of SQL by doing what we used to do in the 1990’s – storing data in a manner that makes accessing it require less IO, putting related data together. Some of us old database types moan endlessly about places not doing proper database design anymore.

But sometimes I wonder if the actual areas of focus moaned about by the old guard are not that significant. The thing they (and now I and many of my friends) also complain about is actually more significant – and that is our attitude towards the process of designing and building systems.

I was not trained in IT at college, I studied biology. But I was trained when I came into the industry, in SSADM, database design, structured testing methodologies, even logical problem solving. And I was lucky to work with people, mostly those bitter old people, who spent as much time teaching me why you do things in a certain way and not just the syntax of a language or which framework to use or which source control repository was flavour of the year.

Looking back over my whole career I’ve encountered a huge number of very average or even poor developers/DBAs/analysts/system designers. And yet some people from every generation are much better than their compatriots, even though they have similar backgrounds and experience. And often these very good people are not apparently any more generally intelligent than the not good ones. Thinking of those good people, I believe a common trait across them is that they listened to the old people complaining and, though they ignored a lot of it, they learnt to ask why things work the way they do and to try and understand the overall technical architecture of computer systems – and not just their little bit. They learnt to consider the whole system, even if some of it was only understood at a simplistic level.

I’m not sure that this curiosity about how things work and the need to look at the wider picture is taught at college (and these days most people coming into IT have come from a college course that either focuses on computing or is a main component of it). If it was taught, wouldn’t it be more common?

I think we learn how to solve problems and design systems from those around us who have done it for real, many times. And that’s those moaning old buggers. But it’s not understanding a layer of technology that is important but actually the total opposite – understanding the wider picture.

I think most people who are good at IT, no matter what their age, were blessed by early exposure to talented (but miserable, complaining) people who simply did things in a sensible, holistic way and asked “why?” a lot. We were lucky.

If you think this whole article is just a plea to listen to me when I complain about the youth of today, you may have a point. But, if you do listen, I might (probably by accident) teach you something that helps your career for years to come. It’s not so much how smart you are but your attitude which makes what you work on a success.

Comments»

1. Raymond - April 23, 2022

Interesting observations and I can say I experience the same issues. I was lucky in the way that I learned analysis and design before programming by chance as I was the material expert in the business and worked closely with the system analyst in the early days. I then became a tester of the system and after go life the application admin. Not that entailed a lot, but alas.

I worked closely with the developers and started to get into programming in my own time. Good old COBOL. I was lucky that one of the developers became a friend and mentor. I bought a book on COBOL, went through reams of printed code to learn and experiment and was assigned some maintenance work and progressed to bigger things.

Still very keen on analysis and design I did James Martin Information Engineering and at that time Oracle came to us. We were the first client of Oracle in the Netherlands. The rest is history as they say. However, if I fast forward to the last 15 years, I always wanted to do something for other people starting in IT, and help them as other people in my life encouraged and mentored me when I started. And here is where the problem came. Many people I encountered had no interest in being mentored, found DBA work boring and let’s not even discuss design and modelling. Mid to late nineties you could not tell the youngsters anything. Put headphones in and program, damn the torpedoes, forwards. Well, we know how that bubble ended.

My career mostly was focused on rescuing projects and applications. A few I had at least the opportunity to do the data modelling and design on the ground floor. My biggest complaints over the years have always been no proper data design / modelling and developers not learning SQL properly and not trying to understand the data in the database.

Some systems I encountered were built like a LEGO model without a template/model to go on from. It’s like giving a child a box of lego and letting your imagination go. I remember when I was young and played with my LEGO I many times ended up short of building blocks or forgot to put in a window and my house looked like a bunker. My Mecano was a different story I always followed the design and ended up with proper working models. Although I once made a mistake with gears and my conveyor belt move only the right way when I put it in reverse.

So does that make me now one of the moaning old buggers? I guess, but I wear that badge with pride.
I am on a project with 2 other moaning buggers and that by itself is an interesting dynamic. I hope I did not overstep the mark of sharing my longish comment. I’ll let myself out now.

mwidlake - April 23, 2022

Thanks for that – an no problem with the length

2. NormanDunbar - April 23, 2022

SSADM! Dear gods, that was a dire methodology. I had to learn it in Local Government up in Aberdeen.

On the course, it was explained in great detail. Basically the analyst doing the, ahem, analysis, wrote more and more detailed specs, then handed them over to the programmers ( as we were called back then).

I told the lecturer that had I been handed a program spec like that, I would probably have decked the analyst! All that was left to do was convert the written spec into code, pretty much word for word. No skill required! Funnily enough he agreed.

As it was, we never used it. Surprise! It was pretty much an excuse to waste lots and lots of paper.

Unless, of course, my memory of those days is worse than I think!

Cheers,
Norm.

mwidlake - April 23, 2022

Ha! Yeah, it was very much a Public Sector thing. It was what was used by the NHS in the late 80’s/early 90’s. I don’t think I could really describe it in any detail to anyone anymore, but I have vague memories from when I learnt it to not take it “too far”. It seemed intended to produce a very specific and constrained specification that the, err, level of developers you often found in public sector then could cope with. As an “Analyst Programmer” and not just a programmer, I was allowed to use my brain.
It still exists.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: