CTO @ Tithe.ly
Building software is hard. It’s an uphill battle and you need endurance as the software matures. Building software is also super satisfying and such an amazing adventure, especially when you start seeing momentum as well as a multitude of happy customers. I think the best software companies aren’t the ones who write the best code but those who can make really good decisions on where to dedicate their time.
We have been using Domain-Driven Design and Hexagonal Architecture for several years in both legacy and newer products we are building. This post is dedicated to why we use Domain-Driven Design and Hexagonal Architecture.
Something on my mind at the moment is the importance of engagement, especially in a distributed workplace. The people who are going to do really well at distributed work are those who engage.
I’ll admit, when I started my first company 9 years ago, security wasn’t something that crossed my mind. I just wanted to build great software and fast. I think a lot of start-ups have this same mentality. Get the product out the door and worry about “all the things” later. This article talks about some of the things start-ups should be considering when wanting to mature in the area of security.
I’ve read Jason Fried’s books and really like them. I’ve known about his software Basecamp for years but always thought of it as some project management tool I’d never need. Boy was I wrong. Basecamp to me isn’t a project management tool anymore. Basecamp is a communication platform. And it comes with a philosophy around how we should communicate with our teams.
No matter who you are, a leader, a peer, a follower, valuing someone by encouraging them is big. Whether you’re all in the same room, on the other side of the office or working remotely, it’s quite easy to fail to remember to encourage those around you.
We started rolling out Scrum across our engineering team this year and we’ve seen some great success so far. When building software, the “when will it be finished” question is always looming in the face of Product Owners.
Onboarding engineers is generally an afterthought for most engineering teams. When you start a project you’re not thinking about how new people are going to be introduced in the future. It’s one of those things I think everyone wants to spend time on but let’s face it, we are too busy coding. This post talks about some practical ways you can onboard engineers and ensure they are mentored in a remote environment.
Before working at Tithe.ly, I was a little old school at my company Elvanto where everyone worked in the office. Now that I’m at Tithe.ly, they’ve introduced me to the world of remote — and I absolutely love it! I’ll do a write up on switching from traditional office space to working remotely in another post. But for now, I wanted to talk about hiring remote engineers.
I’m no night owl. I’m not really a morning person either. I love my sleep. I always have. When I cannot sleep, which is rare, it’s frustrating. Tonight is one of those nights.
