Developer Hegemony

If you are a software developer working at any size company buy “Developer Hegemony”. It explores the way companies treat software developer today and how we stereotypically react to that treatment. It clearly argues that we are treated as glorified line-workers and that we need to move to a model where we are treated like doctors or lawyers with independent practices.

For a long time I’ve called my job a “grind” and that even if I went to a “better” company it would still be a “grind.” Developer Hegemony helped me figure out exactly why I’ve felt this way and although the way out is non-trivial I know that it’s the only way to bring joy back into software development for me.

Don't Put Your Async in My Serverless

A lot of the constructs of Node and modern JavaScript are about handling the asynchronous nature of web server/browser interactions. In a serverless world, single threaded execution is ideal and asynchronous code is problematic. While the title of the linked article (“Node is the WRONG runtime for serverless”) is sensationalist, as the author admits, the article argues Python is a better fit in a serverless world.

I was planning on implementing a project using AWS CodeStar starting from an Express template and porting an existing Express application. I then evaluated the code based on this article and found that I’m using promises for the database interactions. As the author notes, this shouldn’t be a deal killer, but I do need to be aware that using many of the asynchronous patterns common to Node and JavaScript server applications is unlikely to be beneficial in a serverless architecture and harmful from the perspective of unnecessary code complexity.

Serverless development feels like Java in 1998. It has been around for a little while, is gaining traction, but there are still some sceptics. The skepticism around Java was the hype around write-once-run-anywhere. I think that caution was appropriate, but the ideal of a virtual machine that could be deployed on almost any platform to run the same non-GUI code became a big deal.

The big idea around serverless is the reduction of operational costs around deploying an application. The cost of maintaining even virtual machines is tremendous compared to an environment where the code is the only thing to maintain. Just like the vision for Java in 1998 didn’t turn out exactly as people were hyping it; I don’t think we know what serverless will look like in 20 years, but I’m betting it will a significant impact.

In the short time I’ve been working with AWS Lambda and other AWS managed services, I can see the norm for server side development moving away from placing software on even virtualized machines. Programming models that abstract out the notion of a host OS seem like a no-brainer at this point. The reduced cost of maintenance and operation in a serverless environment seems like it would be a win for any type of back-end development.

That being said working for a company that primary tracks and optimizes software and hardware assets in an on-premise environment feels like an uncomfortable to be. Of course, on-premise software and hardware won’t go away, just be reduced in size and percentage of importance. Can a company that is entrenched in the on-premise model morph itself into something that can adapt to this new world and combine and optimize the serverless and on-premise mixed model. That’s the question.

Yay! I passed the certification exam! I’ll have to find a way to incorporate the logo. It’s probably the most meaningful exam I’ve taken since college and I’m glad I’m done. Although I do plan to take the Developer exam and likely the SysOps one as well.

Here’s to a study break until next week.