Purely coming from my experiences so far.

I’m a geek. I’m a programmer. I hack away, I’ve always done code. From some point onward, I also started doing code for money into real industrial and business applications.

It was a fantastic moment to really grasp that what had been merely a pastime, could be turned into my trade. I enjoyed software development ever since.

The elements of change can be categorized easily:

• things that stay the same
• new stuff
• skimming, bubbling, trending and waning stuff

Things that stay the same

Computers essentially still are programmed by making them follow instructions, to manipulate bit-based objects. Things that are made from a series of 0 and 1 bits.

Did you know that most of the surface area, cost and complexity of CPUs is due to massive parallelism? The number of gates, total cumulative “vias” (electron conductors) and related power consumption is due to the fact that it isn’t the basics of computation that have changed, but the sheer “volume” or pipeline that the processor crunches nowadays! Essentially a CPU nowadays does serial computation, but in massive scale – and with some snazzy tricks to avoid calculation of futility. Caching is the technology that fetches a result that is already known at the time the computing instruction hits the execution pipeline.

U canst

What I’m trying to say is that even though you might think OMG! I could never understand CPUs of modern computers, I’d say that’s not true. Zooming in, down to the elementary parts you would still find very familiar concepts: registers, simple microcode (pieces of a actual machine code instruction). The computer’s guts, so to speak, are of the type: IF something THEN do something, ELSE do something else. IF-THEN-ELSE. Add to that a capability to jump (branch execution to other place), add two numbers together, and so on – it’s what makes your machine tick. The rest is performance glitter.

What the software industry is aiming is a few things besides technology development per se:

• managing complexity of a software project, sometimes reaching 100,000s or even millions of lines
• handling the blame game and risks properly
• verifying and testing the quality of software
• keeping software development costs at bay
• if possible, keeping the margins (profit) by applying blue ocean strategies
• avoiding cardinal mistakes of doing an app of tech that no one will ever use (or pay for)

Meta: The process side of software engineering

With more experience under the belt, I got great experiences from methodologies to cope with project complexity, team work, splitting development to many members, solving problems together, and continually improve the way the whole team works.

This is a recollection of things that I’ve encountered. Ideas, methodologies, good and bad ones. Things that worked for me, some that din’t.

I’m not particularly an advocate of any specific one toolbox, whether it is a project methodology or a piece of the tech stack.

Enjoy the silence

You might have periods of silence in the project, and especially during daily schedule. Enjoy. These are often the moments where intense development and raw writing work happens. Coding is something that takes different turns depending on the microtask at hand; sometimes you are basically writing quite simple snippet of code, where you don’t have to hold many constraints or guidelines in your head at the same time. At other times, you’re doing a leap forward in some critical portion, where a lot of “things hang in the air”, and making it all spit out as code is a lot more nerve-wracking. People counter often the physical noise with means such as noise-cancelling headphones. These are really ways to do stuff. And a reminder to all fellow coders: even though we might perceive someone is merely listening to good music and having fun, remember that inside what happens might be a intense concentration and trying to get a complex thing to fit.

Turning fear into curiosity

Frustration can be a powerful force. Sometimes upon initial impact with a project, a so-called handover, there can be friction; you might be looking at a work worth up to several years, when you are entering in midst of a project. There’s a lot of tacit knowledge also present, decisions having been made. A new project being handed over is like a shapeshifting blob of stuff; you’re struggling first to get a overview and familiarize yourself with possible any new tech that comes up.

Don’t be intimidated by initial frustration. It usually turns out fine! Keep asking those dummy questions and keep an eye for possibilities to start chiming away with the code. Usually when you do changes and additions, things start to roll at once.

• identify your emotions
• identify the flow and connections between emotions; did you get frustrated at something, a process, someone particular; at a way of things done, or something that you think should definitely be done?

Ivory Tower – Old Systems Plague

Some large organizations have problems in fallout of obsolete technology. Large HR / workflow systems implemented years ago seemed like a great idea; now, they’re outdated, clumsy to use, and have little if any real positive effect on personnel. Yet no-one seems in position to nudge a change. This is a typical situation that you might encounter.

My tips:

• keep your head cool
• try to find other kinds of users besides yourself; what do they have in it? Someone surely knows how to motivate using the system, otherwise it would’ve most certainly been dumped
• when there’s a chance, be part of the changing force that can make things better

Learn to surf on the cutting edge

In our profession, things rarely are “ready”. That means:

• you will be using software to make software
• software contains always some bugs
• => this means that your tools are not perfect!
• some of those bugs will be visible to you, too
• you will get irritated by the bugs
• you can also control how much you let the bugs irritate you, and
• file a bug report. Or even better: make a patch, and submit that (if the tool is open source and hosted somewhere publicly)

This trend IMHO has stayed essentially the same. The microarchitecture of our tooling has been more finegrained – so on average we’re doing software composed of many more packages, than we used to.

Software stacks – 50000 ft view

Some software stacks might take considerable time to get ready for work. We might be talking about a day or two, typically. There’s some trial and error typically in the process of setup. The more cutting-edge stuff you use, you’ll find that there’s often no single “dogma” of how to do even such a thing as complete setup. It just takes a bit of getting to know the stuff. Explore the options, try to also read first-pass without interruptions and as much as you’d like, it might be better to resist the temptation to go hands-on immediately. So: read. Then start doing, once you got a grasp of the big picture. Otherwise it’s really easy to get stuck midway, and actually wonder how you can undo your half-baked installation.

This is something that is best tackled with patience.

I’ve gone through maybe 20-30ish stacks at some depth. The biggest change that I perceived is that during the last 20 years, rise of open source dogma made a refreshing change in the sense of involvement. Whereas stacks used to be “professional toolboxes” introduced by some big corporation, nowadays stacks are a living project where individual contribution is often appreciated, things move faster, and there’s a better chance of actually reaching a live person to ask about for advice.