When I first started consulting, I had everything tied to my name. My company name was Treb Studios, my email was firstname.lastname@example.org, and my whole business was tied to me.
This was fine for a while…until I started growing. I hired contractors with the intention of replacing myself on my existing projects. This proved to be very challenging.
Clients didn’t want other developers, they wanted Brandon, because that’s what they were promised.
It wasn’t until I started using “we” language instead of “I” language that clients fully accepted my other team members. Changing the language also had a profound effect on how I perceived the company. I began looking at everything as a real company rather than just me hacking on the side.
So, if you are building a company (even if it’s just you), start using the term “we” instead of “I” from day one. It will make the transition much easier when you start growing, and it will make you feel like you are actually building something beyond yourself.
Tonight, I'm going to a party for local entrepreneurs.
I was getting ready for the party and thinking about the signals I am sending with every detail I put into my appearance. How do I want to be perceived? Should I go combover or faux-hawk, slacks or jeans, watch or Fitbit, leather or suit jacket? All of these decisions don't necessarily paint the picture of Brandon, so much as they paint the picture of who Brandon wants you to believe he is.
While it may seem vain to contemplate on what signals I'm sending, people do the same thing ALL THE TIME without even being conscious of it. We do this not only in real life, but especially on Social Media.
Seth Godin will often write on sending signals.
He has a great quote from the post:
Empathy helps us understand what will be received, and intent dramatically improves our effectiveness.
Understanding that you are always sending signals AND having empathy will not only get you further in business (since you can understand the signals you need to send on an individual basis), it will also get you further as a human being.
This also has me wondering. What signals do I send to myself?
I have really been enjoying listening to Darknet Diaries lately. It’s a Podcast about hacks and software security vulnerabilities.
The show really makes me realize how crappy and insecure most software is. Most importantly, it has gotten me much more security-minded in the software that I build.
If you aren’t already listening to it, I’d suggest you check it out. You will soon put on your tin foil hat like me and start to believe everybody is trying to hack you.
My wife and I are hard core “type-a” people. I mean, so planned that we send each other calendar invites for date night (don’t judge what we consider romantic ;)).
I didn’t used to be like this. When I was younger and in college, I was a total scatter brain, a C student by choice.
This all changed the day I was laid off and had to start my own company. Owning a business requires me to pay attention to every detail, every invoice, dev rate, hours budget,etc… Its exhausting and college Brandon would have been out years ago.
Fortunately (and I can already feel this sounding like a sales pitch), I use Bullet Journal. It’s basically a system using only a notebook and pen to organize your life. Think 90’s style leather day planner.
While I don’t use every “module” that it offers, I use the system to manage todos, notes, long and short term goals, and lists (this blog post title just came from one such list).
So, if you are like I was, I highly recommend bullet journaling. It will change your life for the better (worse?).
Many of you might not know this, but my family and I live in a converted schoolbus.
Today, I had quite a few “bus chores” and I figured that I would share them here because together, they do seem a bit odd.
- Change composting toilet
- Fill up propane tanks
- Add heat tape to fresh water lines
- Replace RV vent in roof because it started leaking
Sometimes I wonder if I have more chores on the bus than in a traditional home.
Whatever, off to chop wood for my tiny wood stove…
The other day, I was having a conversation over Slack with my development team. They were working on a client project (and doing a killer job), and there was a particular UX pattern that seemed very unintuitive to me. This app was designed by the client, so there was little the dev team could do beyond making suggestions, so they went ahead and implemented it per the spec.
After fiddling around with it for a few minutes, I literally couldn't understand how to complete the particular task and had to ask the team lead for some help. He assured me that it made sense and offered to walk me through the architecture and data models to help me better understand the flow.
Sometimes, as developers, we understand these super complex systems solely because we architected them. They seem intuitive to us because we know the underlying data structures and algorithms involved. When we are speaking to other developers about those systems, they usually get it too, because they understand things at a software level.
This doesn't always translate well when it comes to UX design for the end-user. I believe developers have a bias when looking over the product in which they are creating. It makes sense to us, so it must to everyone else. I opted to not learn about the underlying code, so that I could better QA the product by removing some of this bias.
Next time you are testing your software, have as many people not involved in the project test it as possible. Given them very little context. Watch them use your product. Find out what is intuitive to them and what isn't. You will be pleasantly surprised and your software will be better for it.
How to Retire Forever on a Fixed Chunk of Money - Mr. Money Mustache
Another solid post from mmm. His blog was one of the first I read that set us on the path of financial freedom and minimalism.
If you don’t already know about him, I’d suggest starting at the beginning and reading through all of his posts.
I promise it will be worth it.
My little brother was recently in town for the holidays. He’s about to graduate from college with a CS degree, so naturally we talked about searching for a job.
I figured I would share the advice I gave to him here in hopes that it might help others.
- Don’t be discouraged when you get turned down. Having hired many employees over the years, I have learned that there are so many reasons to not hire a candidate. Much of the time they don’t even have to do with qualifications. In the past, we would just interview with no intention of hiring to test the waters.
- Work with recruiters there is little downside in working with recruiters as a job seeker. Give them tight parameters about what you are looking for (position, location, etc…) and tell them not to bother you unless there is a match. Often, recruiters will have better “ins” with hiring managers, so your resume won’t get filtered as often by some algorithm.
- Network I almost wrote that in all caps. Attend local meetups, take people out to coffee, and get connected in the local tech scene. Don’t give me that “I don’t live close to tech” nonsense . I live in a suburb of ABQ (not a big tech town) and still managed to build a killer network of tech locals.
- Always be searching for a job (especially if you already have one). Part of your job, is to find a job/a better job (or at least leverage to get paid more in your current) (longer post on this later).
- Shoot for the stars, but be ok landing on the moon This is more for new grads. Landing a job will give you that confidence boost you need to begin your life outside college. So, don’t stress about landing the dream job at Google on day one (by all means apply though). Just take a job and then see the previous bullet point.
Happy job hunting!
As developers, we spend so much time perfecting our craft. We are always on the hunt for hacks, tips, and tweaks.
We always set out to write the most clever and reusable code possible. This is all great…until it’s time to ship.
I have seen it time after time. Developers over-optimizing their code, writing protocol after protocol. All the while, they slip further and further behind schedule.
When the client asks the dev about the delay on feature X, the dev proceeds to explain the super cool reusable, component-driven,state managed, highly available, future proof, buzzword, buzzword system they are creating. The client literally doesn’t care about all that. They just wants to see feature X working.
I love clever code as much as the next developer, but sometimes you’ve got to table your inner CS geek and just ship something that works. Then, refactor later.
In our house, we often joke that “the diet starts Monday”. Usually, this is in response to some conclusion that we are not currently on the healthiest path.
Procrastination is in our DNA. We put everything off until the absolute last minute. For me, it’s usually side projects. Projects that I know will make some revenue to supplement some of my consulting income. It’s my goal to eventually move on from consulting, however that has been on my “resolution list” for years, with little progress.
I’m committed to finishing one such project before the years up. I should get hacking on it…on Monday.
It’s often much easier to have a sense of gratitude when things are going well. As humans, we are prone to focusing on the one bad thing that’s going wrong rather than the multitude of good things going right. This traces way back to a time where we needed this sense to stay away from danger.
My father-in-law was just admitted to the hospital with lukeumia. Although this is one of the harder times in our family’s lives, it’s really been a sobering experience giving me a stronger sense of gratitude for my wife and kids.
I appreciate them more now than ever and am grateful for their health and spirit.
I wish you and your family blessings today, and pray that you too can always find gratitude, even in tribulation.
“Just hack a quick proof of concept, we’ll rebuild it when we get more funding.” These are some words I often hear from clients who have minimal budgets.
They generally want my team to build something small/quick/cheap to get their concept across in hopes of securing more funds down the road.
What I have learned by saying “yes” to these types of requests in the past is, those quickly hacked prototypes often end up in production.
While this is not necessarily a bad thing, it’s sometimes problematic if we viewed the code as disposable up front. Normally, a client will have you ship a prototype and then will want to quickly iterate. If you are not careful, you will soon accrue technical debt and eventually sour your relationship with the client due to underperforming.
So, if you are ever asked to do a quick prototype, do yourself a favor and treat it as if it will be production-ready from day one. You never know how long you will be supporting it.