Cranky Tech Rant #1

(#1 because yeah, there will be more)

I am really tired and a bit angry at people calling themselves “React Developers”.

No. Please. You are a JavaScript developer working in React.

Just like right now I’m a Ruby developer working in Rails.

It’s really easy to lose sight of the language at the core, and the fundamentals that go with it, if we forget what the foundation is for these frameworks.

This could be expanded to saying “You are a DEVELOPER” and please don’t put a language-specific label on it, but then, that’s because I like being a polyglot. That’s not everyone’s cup of tea, for sure.

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?

Weekly Focus 2018: 9.9-9.16

  • LSQ
    • Plan 2018-2019
    • Write Editor’s Ephemera
  • Storybin
    • Sprint work – Testing
  • Studying
    • Rails Guides
    • Topic lists
  • Enrichment
    • Stirring
    • PPY updates
    • Skyrim post
    • Debugger cards

Last week’s focus list was ridiculous in hindsight. It listed all the things I wanted to do rather than the actual focus themes for the week. So I’ve adjusted this week. A lot more streamlined and, well, focused.

Did a lot of LSQ planning over the weekend and that will continue. Dates for things may change, but I need to know the shape of the thing so I can hopefully avoid crunches and make informed changes if things go off the rails.

I also have my monthly column to write and would love to get a month ahead. It always sneaks up on me.

Storybin had no progress, instead I worked on the LSQ website rebuild, but that can’t happen again this week. There is some learning that needs to happen around that work in order to do it, so that will be done as well. Which leads me to…

Studying is being reduced to reading the Rails Guides and working on a list of topics to review. I’ll jot things down as I encounter them and start doing some targeted studying. I’m functional but I want more fluency. This will help as I start seeing what I don’t know as gaps in a structure rather than one big gaping hole of ignorance.

Enrichment is the same as las week, but with an addition, unlike the other areas of focus. I came up with an idea for a useful set of cards for debugging and will work on those prompts on and off as they come to me.