Software solutions to human problems
This is part 2 in a series on ethics in the tech industry. In this post I’m going to explore the topic of addictive apps and technology. What roles do they play in our daily lives? How do technologists use psychology to drive engagement? How do we decide if an app exists for the benefit or detriment of the individual and our society?
This post means to be the start of the conversation, not a prescription of a solution. continue reading →
Tech is at a cross-roads. The move fast and break things mantra of Silicon Valley is actually breaking things.
Regardless of whether or not the people making the decisions at Facebook were bad actors (or negligent), the hands building this stuff have a responsibility as well. Despite how smart the engineers of the world think we are, we’re still easily manipulated and blinded by an idealistic vision. The hands that built these platforms may have only intended good to flow from their existence. continue reading →
It’s a transition that’s been rehashed by many before me: going from developer to manager. I’ve been making this transition over the last six months at Cratejoy and thought I’d share what I’ve learned so far.
For context, Cratejoy is a relatively small startup with about a dozen engineers. Before myself, there had only been two other engineering managers (our CTO and my boss). You could definitely say my “training” was ad hoc. continue reading →
A few weeks ago, Jonas Downey from Basecamp posted an article about how they handle software changes while keeping their customers happy. The topics covered are eerily relevant to a recent initiative at Cratejoy. I want to share how I think about and deal with what we define as “product debt.”
If you haven’t read it, Downey’s central point is that to keep customers happy, you simply can’t remove features. continue reading →
A maintainable codebase, the holy grail of every software architect’s dreams. For some engineers, it’s something we obsess over: a harmonious construct of easy-to-modify code, a product that can we can remold to the changing requirements of our customers. Unfortunately, the “business reasons” for investing time into writing good software are less clear and often misunderstood.
Flexibility has always come at an expensive cost: time. We’ve found practical, quantifiable ways to justify a focus on maintainability: reduced hours fixing bugs, faster iteration cycles, quicker on-boarding of new developers. continue reading →