Blog
Random thoughts on technology, leadership, and entrepreneurship.
Architecture Principles - Knowing What is Happening When and Where is Better than Simple Solutions
Knowing What is Happening When and Where is Better than Simple Solutions The primary concern here is that Software Engineers are Professionals. Professionals are, with varying degrees of definitions: Trained Experts Knowledgeable Communicative Collaborative Disciplined In other words, the things that separates a Software Engineer and a Software Developer are the soft skills away from the computer. While I always prefer simple over complex, experiences Software Engineers know that there’s a critical skill that “simple solutions” sometimes obfuscate: knowing exactly what is happening where, when, and why.
Architecture Principles
Now that things have started to settle, I wanted to start to write down my views on software architecture. Most of this has been bottled-up knowledge or hidden behind corporate firewalls of documentation. So, as best I can, I am going to put fingers to keys to put out my overarching software architecture principles and thoughts. As a software architect, I’ve had the blessing to work in really good software systems, really challenging software systems, and everything in-between.
A Pause
A Pause Many of you may have noticed a lack of progress. The time from collapse to new chapters was chaotic good. The end result is that since 6/1/2023, my time was full of non-coding, non-learning opportunities, so I paused on Python3. I debated unpublishing the posts to avoid the risk of some poor soul finding them and thinking that’s how production code should look, but I think I made it clear what the status was.
Learning Python and FastAPI - 02 - HTTP and Routing
Reminder This is a documentation of my attempt to learn Python with FastAPI to build a simple API. I prefer to learn new tech by doing. This is akin to journaling and is not intended to be used in a production environment. It is a learning experiment. For more information see: Project Overview and Reasoning Previous Post Meanwhile Since completing the initial set up, I spent a lot of time in the official FastAPI docs, which are fantastic.
Learning Python and FastAPI - 01 - Set Up
In this post, we will cover getting set up with Python 3 on an Ubuntu machine and making sure we are good to get started. Reminder This is a documentation of my attempt to learn Python with FastAPI to build a simple API. I prefer to learn new tech by doing. This is akin to journaling and is not intended to be used in a production environment. It is a learning experiment.
Learning Python and FastAPI - 00 - Overview
Overview The goal of this series of posts is pretty straight-forward. I know that I personally learn by doing. I have a project I use to try to learn new tools. It’s a bit more complicated than, say, building yet another To-Do app, but it isn’t as complicated as architecting a very complex, production-ready system. I am going to dive into Python and FastAPI, mostly because Python is exploding in popularity again, it’s been a while since I’ve used it professionally, and it’s a good toolset to have under the proverbial belt.
When it Crashes Down
Well, what had been bottling up finally broke through. It’s really hard to believe. Like other crises, it happens very gradually and then all at once. I can’t get into it too much, but today was my last official day at Wagz, Inc. I will continue to provide support as available. For those who know me, Wagz has been a startup I helped build since 2016. In that time, I’ve watched junior engineers grow into outstanding leaders and experts.
Learning New Tech - A Project Overview
Background Learning a new technology can be a challenge. Everyone learns differently and has different preferences. I prefer to learn by doing, but there’s a catch. At some point, the guides and tutorials you find give a gap. A lot focus on introductions to the technology, and maybe get up to something as complex as a To-Do clone; then you have the really advanced examples or cookbooks that show how to do one thing and assumes a lot of prior knowledge.
Tech I'm Using - 2022 Edition
The benefit of teaching is I get to answer a lot of questions and share a lot of gathered experience. Looking into 2023, I figured it is long overdue to just write down a quick summary of what tech I would use to start a new project and what I am excited about potentially diving into. So, without further ado, let’s do it. Backend I’m still a Go diehard. I’ve used the language extensively and I absolutely love it.
Software Engineers and Motivation, Part 2
In my last post, I provided some background on to why I was interested in exploring motivation with regard to software engineers. In this post, I will explain my findings and some implications of the research. After I posted to research instrument online and briefly advertised it, 1559 respondents began the survey and 1054 completed the survey (n = 1054). That is a completion rate of 67.6%, which is pretty good considering the number of questions; people are busy!
Software Engineers and Motivation, Part 1
In 2016, I wrapped up my took-forever-but-worth-it dissertation for my PhD in Business Administration and Applied Computer Science. Given my background, I took a psychological approach to my research and decided to explore something that has always interested me, but could also make for some valuable insights. I explored what motivates software engineers in a general sense. You see, motivation is a tough egg to crack. There are many different theories and insights.
Wrong Tool for the Wrong Job
I am happily employed. This has not always been the case. Here, I share a few stories and anecdotes, both from me and from several of my peers. In order to move quickly and flexibly, developers need to be happy and have the right tools. The right tools can enable developers to do amazing things, while the wrong tools can hinder motivation, efficiency, and agility. What the “right” tools are depends on the job.
Offices are Overrated (Especially Open Offices)
Developers are expensive. Hardware is cheap. We’ve heard that maxim time and time again. We use it to justify automating every possible task in the developer work flow. We use it when selecting languages that are more productive but less efficient. Its true, especially when servers are pennies or dollars an hour, whereas a junior software engineer is making $25+ hour ($65,000 / 2040, give or take). So the goal of any business, especially a lean business, should be maximizing the work we get from our developers per hour.