On Certification

“Software Engineering”, a field of interest launched in 1968 that aimed to bring product design and construction skills to computer scientists by having very clever computer scientists think about what product design and construction might be like and not ask anybody.  – Graham Lee

The idea of certification and licensing for software engineers came up in a Slack I’m on. Of course I accidentally ended up writing a wall of text that really needed to be a blog post, so here we are.

I think those algorithm coding white board tests used by many tech companies to vet potential employees are meant to be some kind of measured standard. However, as an industry it’s been collectively decided (mostly by default rather than intent) that there should be alternate paths to a career, which makes that kind of standardization feel like more like gate-keeping.

Additionally, the vast array of technologies available make it hard to quantify knowledge like that. Are you certifying for front end, backend, general knowledge? Say you’re going to have multiple certificates. If it’s front end, are you standardizing a particular language or even framework? How long would such a thing be valid for?

Setting standards also means being able to take a step back and evaluate the industry as a whole. It would surely slow progress of new technologies, but then I don’t necessarily feel that’s a bad thing, if I’m being honest. Move fast and break things was meant to be an approach to solving problems in new ways (yes, and make money fast and easy) but unfortunately seems to have taken the discipline of writing software along with it.

It’s all something to think about, and standards, if not licensing as other engineering disciplines have, is not the worst idea I’ve ever heard. I even say this as someone who didn’t graduate college. If licensing was put into place, I’d be out of the running and at the same time I feel that so much software is built in a way that’s harmful to users and maintainers alike that something should probably change.

React, Rails, and the degradation of the developer experience

The web development field is a mess. Tutorials only 6 months old are out of date. I’m dependent on stack overflow for answers to everything. I spend more time fighting config files and setups than I do writing code.

I wouldn’t want to scare anyone away, but I would be tempted to give dire warnings to folks looking to get into web dev right now. There is a shit ton of bs involved that has nothing to do with building apps or changing tech culture. Our tools are busted & confusing as fuck. It’s only because I’ve been at this so long that I can calmly navigate this quagmire.

I don’t mind learning new things, but that learning needs to feel like I’m getting something sustainable out of my time. Honestly, I don’t think “always be learning” is healthy. It’s the nature of the beast, but I don’t think we’re built for it. I just would like the industry to get to a point where there’s a sense that any of this is learnable with consistency.

I’ve literally lost interest in React before I’ve even built my first app in the framework and that’s entirely to do with the amount of learning that has to go on that has nothing to do with what I’m trying to build.

I’m just looking at all this and seriously questioning what we’re getting out of it. How is this better than the PHP apps we were building 10 years ago? It’s a slightly better experience for the end users? Maybe, but there have been other related innovations that make things faster. I mean, I built this site on WordPress for a reason. It’s fast, it’s got a stable UI, it does predictable things.

Are these web apps we’re building really anything more than html forms and pages? Is this really any more straightforward (and powerful) than what we were using a few years ago? I was working through a React course last week and the instructor half-jokingly said he called himself a “professional forms developer” which is scarily accurate for what many of us are actually doing.

There is room for innovation. I just wish it was happening a bit more slowly and thoughtfully. I think my last year of working with Rails has had a big influence on how I’m feeling about this stuff. There are changes to Rails, but it’s measured. JavaScript-land is a hot mess in comparison. The Rails apps I work on are plenty quick and responsive, even on mobile. Most of the time, there’s little to no javascript involved. Okay, fine, I’m blaming the single-page application fad.

All of this complexity is supposed to make the “developer experience” better. We’re meant to be more productive and write better, more stable code by using these frameworks. I’m just not seeing that play out so far in practice. If we’re not even having a better experience doing the work, then what is the point of all this, really?

At the end of the day, I like building things. I really do. Today is just one of those days where the barrier between what I’m doing (and where the industry keeps going) and being able to build things is very very high.

On “Software Engineering”

There was an xkcd comic going around a couple weeks ago. It was funny in a disturbingly “it’s funny because it’s true” way. Further driving the point home was this article on writing software tests I read this morning, where Process Engineering practices used in industrial planning is compared with Software Engineering practices for building applications.

Much of software built today is created with some level of testing applied, at least on the back end. The front end has been slower to integrate testing, though the tools are just as strong. But in both the front and back end, testing is seen as a necessary evil at best, and an unnecessary burden at worst. A lot of this sentiment, from my experience, comes from a couple different sources.

First, is simple ignorance. The way many of us have entered the industry, through various levels of self-teaching, means there are gaps in understanding of best practices. As someone who came in this way, I’m hyper aware of these gaps and work to fill them. Testing is one of the most difficult skills to learn for a newcomer, especially if you’re learning on your own. I can’t speak for the bootcamps, having never attended one. I like to think they teach BDD or TDD as a matter of course.

Second is cost. Testing takes time. In the startup world of “move fast and break things” the things that break are supposed to be the old ways of doing things, opening up the opportunity for more efficiency and a better ways. When testing is sidelined in favor of pushing out a minimum-viable product, what often ends up broken instead is the code base, the application itself and the bread and butter of the business being built.

Third is, quite frankly, laziness on the side of the developers. Testing takes time. It means having planning in place. It means thought processes must be applied to ensure the functions being written do their job properly. This means that you can’t just dive in and start writing code, something most developers will tell you is the “fun” part. So there’s a big avoidance factor at play as well.

Mechanical engineers like my father chuckle about our industry’s use of the term “engineer”, and rightfully so. While there are many folks who work hard to plan and test, there are many more who prefer to dive in and start writing code without those practices. When the software does not work as expected, or becomes more and more difficult to maintain as the bug list grows, none of us should be surprised.

If we are to model ourselves after the aircraft designers and the building engineers mentioned in that xkcd comic, then we need to embrace their practices of testing and planning as well.

The software we write infects and effects the world around us. Algorithms rule everyone who touches the internet now. Software is dangerous, it’s a tool that can and is used as a weapon, a subtle knife used to stab more often than not. We have a duty to everyone on the planet to get our shit together as an industry. Otherwise, what the hell are we doing calling ourselves Engineers?