In this article, I discuss some of my thoughts on how tools can make some tasks harder while making others easier and what it means for our organizations. I also go into why adopting a tool that makes some tasks harder may not be all that bad and touch on a strategy or two for managing these tools. I’m considering this a first public draft rather than a final article. I am curious how you all see it.more⇛
Your team has a list of tasks that need to get done. How do you decide who does what? It seems simple on the surface but as soon as you start thinking about it, it becomes more and more daunting. This time around, I’ll discuss how I prefer to do it and why. Hint: it doesn’t start with just assigning everything and hoping it gets done.more⇛
We often use building construction as a metaphor for software development. This time around, I explore the aptness of this metaphor a little bit in light of my own background in both.more⇛
I starrted dabbling in the new-ish programming language Rust a few months ago. While Rust reached 1.0 in 2015, eight years old is still a baby among programming languages. Nearly everyone taking on the topic “why Rust” will cover the same key features: memory/thread safety, performance, and the ease of distributing applications built with it. Those are the “sell it to the CTO” features. In this post, I cover some of the other features that are a little less flashy but that I think make Rust a pleasure to work with. Fair warning: this post is tech heavy.more⇛
I asked this question on LinkedIn: “What kind of medium severity bug would you rather have in your system?” The options that I gave were 1)a feature bug and 2)a security bug.
While I only ran the poll for a week and didn’t heavily promote it to get more views on it, the handful respondents were unanimous: they would rather have a feature bug. I am not at all surprised by that result. This article will explore that a little bit and dive into a common cause of security bugs.more⇛
subscribe via RSS