Information Systems Engineer, or Info-Engineer?

A content engineer is a tech person who uses tools to create, deliver, and make available relevant content in some sort of automated fashion and in various formats for a variety of audiences. At least that’s one way of interpreting the “content engineer” title – it’s sort of a new field.

We all know what an information systems engineer is – the person who fiddles with all the servers and network equipment to make your life difficult. Just kidding – to solve all your problems.

So… info-engineer

This is something I kind of just made up. Maybe somebody else already has an idea about it and has written about it, but not from what I can tell after a morning of research.

In my view, an info-engineer falls somewhere between the content engineer and the content marketer / strategist. More in the realm of automation and process, but also doing a lot of crafting of content as needed. But the focus is on information, not on systems. Systems only exist so that we may better use information, after all! Working effectively with information (a type of content) is the key.

The info-engineer doesn’t simply create content, but also creates processes and identifies obstacles to the efficient creation of content – without any fear of getting hands dirty with manual content crafting integrated into the whole process.

The information systems engineer, in contrast… does other stuff… techy stuff.

I’m thinking the two of them should cross paths more often! 🙂

You Need a QA Evangelist

The internal IT team at most organizations gets killed by user support.

Okay, those are strong words. Truthfully, it’s not so dramatic. And if you’ve got your eyes open, your user support will help you grow valuable experience far quicker than it drags down your engineers.

But user support is a significant challenge that can stymie project progress. And unfortunately most of the problem is self-inflicted by organizations. We build and deploy buggy systems. And we allow buggy work processes to continue.

Bad QA. Or none at all.

You need someone to take responsibility for that. Product companies have teams of software testers and other folks with a primary job function to ensure quality. But somehow organizations don’t do that for their internal systems development. Quality may be viewed as a shared responsibility, but nobody executes their daily work with commitment to quality as the driving force. And a typical engineer or manager simply isn’t trained to ensure quality or to reliably identify process problems that allow quality to degrade.

Meet the QA Evangelist.

Not every organization is going to be big enough to have one. (Smaller organizations can partly make up for QA problems by being agile enough to quickly fix them, together with a collective willingness to accept unsolved problems.)

For organizations where it makes sense, the QA Evangelist is not a manager, and not an engineer. This role should be able to work across multiple teams, and should do so from the point-of-view of a subject matter expert who excels in promoting a quality mindset. But no good burying this role in the trenches as the only poor soul who has to do QA (engineer), or kicking them upstairs where they’ll be so embroiled in politics they can’t make a difference (manager).

QA should be approached not as a top-down mandate to eliminate all problems, but as a grassroots, consensus-based, pragmatic process whereby quality grows out of the team’s strengths, and in ways that make the team feel positive about the change.

Everyone thinks quality should be better. Everyone thinks it’s everyone’s job. But without someone in tech whose primary motivator is quality, your only chance at quality assurance will be to have an endless supply of nagging users who are very tolerant of unsolved problems.

Get ahead, and evangelize the solution!

Ops to Dev to QA to DevOps

It’s been a long walk through a lot of technology jobs and roles over the years.

Lately there’s been a trend in tech to create a role called “DevOps” – meant to bridge the gap between traditional development and traditional operations. So, when done right, it should align the goals and outcomes of “what gets built” and “what gets used.”

But it seems like the role usually gets applied to a very narrow field of technology – mostly the Unix / Linux world, and mostly about server deployments and rollouts.

I might be simplifying things. (But, hey – what’s wrong with simplifying things? :-))

I’d say, this idea of bridging gaps and aligning goals between “what gets built” and “what gets used” should apply to… everything that gets built, and everything that gets used!

In my various tech roles, I started out doing all sorts of desktop and server support. At the time, I always wanted to be a programmer. So at some point I became a programmer, then shifted back to more admin stuff for a while, then did a longer stint as a programmer. Following that I had a time as the guy responsible for making sure software quality was high (Quality Assurance) – that’s a kind of bridging of gaps between dev and ops, right?

Finally, I’m at a point in my career where I’m trying to pull it all together. Trying to use all the various bits of tech experience and organization know-how to add a type of value that most organizations seem to lack.

A lot of it is tied into my efforts to make everyone in the world into a programmer. (See CoderDojo Metuchen and So What If You’re Not a Programmer.)

DevOps, in my view, is about ensuring that everyone in the tech department has the best tools available to build, do, and support their jobs.

Doing that requires knowledge of and experience with nitty-gritty configuration and service details, as well as the tools and brains to be able to query, modify, deploy, monitor, investigate, and support all the systems and engineering projects that depend on those details.

The field of DevOps spans development, quality assurance, operations, server support, user support, desktop engineering, application engineering, systems integration, software architecture, etc., etc…

Sound exciting? Yep, it is. 🙂


Tests, Monitors, and Exception Reports

Technology breaks. All the time. No matter what you do. Not just because most technology is fragile, but mostly because most technology solutions and requirements are so complex and subtle that it is really hard to figure out what to do, let alone how to do it reliably.

So you need three things, to keep a good handle on what’s going on, what’s going wrong, and what needs to change to make things better.

Tests. Monitors. And exception reports.

If you don’t have them, you’re never going to get your technology sorted out or working well.

Get them. Get them done right. You’ll be glad you did.


Learning Programming the Way Kids Do

A few weeks ago, me and a couple of neighbors from our town in Metuchen, NJ started up a “CoderDojo” – it’s a programming club for kids that we are running at the local library.

I’ve been a programmer for a long time, but it turns out there’s all sorts of interesting educational tools out there that are exactly what we need to get these kids working on at the club. It’s a lot of new stuff for me, using lots of cool and fun technologies. A lot of it centers around a project developed at MIT called “Scratch Studio.”

So lately I’ve been learning about how Scratch works, and trying out some simple animation and game ideas as a way to practice basic Scratch programming techniques (and keep one step ahead of the kids we are mentoring!).

Here’s my latest creation – it’s a silly little maze game where you have to bring the blue snack over to the yellow creature. It’s got lots of bugs and there’s lots of ways I could make it more fun (that’s the beauty of programming!) but for now, it just kind of works…

Check-out Maze-Dot!

For more info about what we’ve been up to with the club, hope you’ll check-out our website.

Moving to Deployment

A critical aspect of any technology project is how to move from the stages where you do all the heavy lifting and hard work, over to the stage where users can actually use the system.

Flat Design Icons Set Of Vector Line Prototype Promote Idea

Some would say that the heavy lifting starts there!

Getting the system to the users can be hard – despite the fact that the obstacles are well-known, have been with us for as long as I can remember, and are really not so hard to avoid – challenges remain, and they are significant.

For example, often some of the most critical people in the project don’t become involved until the eleventh hour. If it’s an enterprise line-of-business application, maybe you didn’t talk to the folks on the fifteenth floor in Marketing about what they really need the app to do.

If it’s a consumer-facing product, maybe you didn’t get any real users onto the system during any phase of the development and testing.

Another way things can go – sort of the opposite of not getting the right people involved until too late – is kicking people off the project because you don’t see their role as being one closely involved with deployment.

For example, a new system will have the potential for a huge number of bugs in core functionality as soon as it actually gets in front of users. In fact, the software might seem practically unuseable at the start. But the best people to fix those bugs are already working on something else and consumed with new problems.

So get your developers into the deployment!

Assign one of your most trusted programmers to be immediately available to fix problems: Fix the problem, get the users back running the system, get more feedback, improve the system, etc…

Both of these are good ideas – basically getting and keeping the right people engaged at the most critical moments.

And yet, we rarely do either of these things, and we feel the impact of the poor alternatives.

Deployment doesn’t have to be a drain on user productivity or an obstacle in the road to future product development. If you look at it instead as a valuable opportunity to efficiently make huge gains in system quality, then you’ll really start to benefit from all that deployment has to offer.

Got a deployment story you’d like to share? 🙂