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.
I always receive cold emails. Some of them are personalized, and some of them are robotic. Sometimes, I’ll ignore and sometimes I’ll respond with something snarky (this is my spiritual gift). I get it. These are just part of the internet.
Whenever I get a cold email from someone local, it’s a different story. I always feel sorry for them. They have totally missed an opportunity to connect with someone in real life and possibly a sale.
These are the emails in which I’ll generally reply with some practical advice.
If you are desiring to cold email people in your area
Rather than emailing “Dear Brandon, I really think your business could benefit from our website services.”, you should always do at least 5 seconds of research.
Start by saying “Brandon, I really loved your post on Staying Fit With 3 Kids, I’d love to buy you coffee and pick your brain”. This shows you are interested and care about them at a human level (which you should anyway) and greatly increases the chances of them buying the services you are selling.
At worst, you will have connected with a likeminded individual who could/would potentially refer others to you in the future. At best, you could get all of the above plus a new customer and friend.
So, the next time you are cold emailing someone who’s within driving distance from you, give this post another read and consider a more personal approach.
It's been around 3 weeks since I started blogging every weekday. This experience has been nothing short of delightful.
While I have seen many improvements in my communication (written and verbal), I believe the best benefit is around the community.
When I started blogging in 2008, my posts used to have upwards of 100 comments. Granted I was a renegade blogging about iOS in a time of Apple's dreaded NDA. I absolutely loved the feedback and the community that was forming around my writing. I have been blogging on and off since then and have never felt that same spark.
This all changed, when I made a commitment to writing daily short-form blog posts and posting them to micro.blog and twitter. I began to receive comments, and these comments turned into real discussions.
This has been a blast as I'm now able to connect with so many wonderful people in the community. We are sharing thoughts and ideas and challenging each other’s beliefs on tech, business, etc…
So, I challenge you. If you are on the fence, just stop worrying about the quality/frequency/etc… of your writing and just write. And once you have written, share it with others. I promise you, the community you will build is worth it!
I was recently listening to Episode 344- 10 Strategies To Be Happier Through Gratitude on the Tim Ferris Show. Oddly enough, I much prefer episodes where Tim is absent. I do love him, but sometimes feels he steals the conversation.
Anyway, the episode was hosted by a guy named A.J. Jacobs. Jacobs wrote a book on gratitude and is known for traveling the world to thank over 1,000 people involved in his morning coffee (think farmer, roaster, truck driver, etc…).
While I loved the episode, there was something super interesting that I took from it. Jacobs keeps a notebook where he writes down just one thing that he takes away from every book, podcast, and blog.
I love this idea. Often, I will read something, get super inspired, only to forget about it and never apply it.
I feel that this is a great strategy and think it will make for an interesting post on this blog every so often. Think of it as mini book/podcast/blog reviews that highlight what I found to be important.
So my “one thing” from that episode is to start writing down the “one things” from other pieces of media.
I had the amazing opportunity today to hit File -> New Project today. There are few feelings in the world as great as the optimism that comes from starting a brand new project.
“This one will be different”, I murmur to myself. “I will keep it clean, organized, and free from hacks. “, I cheerfully gloat.
Why is it that it’s so hard to follow through on this philosophy? I said it yesterday, coding is hard. Requirements change, clients change, and most notibly, we change.
“End of the project Brandon” is usually cursing “Beginning of the project Brandon” for using some library, not commenting his code, or lazily failing to follow best practices.
But not this time, oh no. This time WILL BE different…
(follow up post to come in 3 months making fun of this one)
I have been building software for clients for over a decade now and have come to one solid conclusion: deliveries suck.
Maybe I'm just the worst developer in the world and have worked with the worst teams and have had the worst clients… but I doubt it.
I have delivered early, on time, late, with more functionality, exactly the same, and in some cases less functionality (usually due to lack of funding) and still…rough deliveries.
When I say “rough deliveries”, I usually mean angry clients and stressed out developers. Maybe not angry like the hulk (though I have seen it), but at the very least, passive aggressive comments, notes of disappointment, etc…
The reason deliveries are hard is because of a misalignment of expectations. When a client has an idea in their head of how their product should look/feel/function and it's been burning in their mind forever, us developers are doomed from the get go. We can never deliver perfectly to match this magic piece of software that only exists in our client's mind.
Also, software is hard. It's especially hard to get exactly right on the very first pass. Software is a living and breathing entity that needs lots of care and feeding. It's very tricky to articulate this to someone who doesn't understand that and is paying you 10's of thousands of dollars to build their dream.
We follow a pretty strict agile process, so the client usually sees their build at every…single…stage. They also have full control to report issues, make changes, etc… during the build cycle. Still, for some reason, they are always dumbfounded when it comes time to ship.
So, if you are building for clients, cut yourself some slack. Know that deliveries will be tough and most of the time, there is nothing you can do to prevent that.
I was having a conversation with my dad the other day and sharing some of my current business ideas with him. I also mentioned that I often discuss new product/business ideas in public with other people.
His response was obviously “Why would you just give away your ideas?”. I then proceeded to give him the "Your Ideas Are Worthless Without Proper Execution” spiel.
So, to put my money where my mouth is, I will be sharing my business ideas here; putting them out there in hopes that either a. I get valuable feedback/encouragement or b. someone else builds it and I get to use it.
So many people have RVs that are in use roughly 5% on the year. The other 95% of the time, they sit in disrepair and usually cost the owner money to store them.
While many sites like RVShare exist that allow you to essentially "rent out" your RV, they still pose a huge challenge in that the RV must be physically located on the owner's property.
I propose to build an RV storage facility where owners receive the following:
- Free Storage
- Free basic upkeep
- Free cleaning
- Profit Sharing
In exchange for this, they allow us to rent their RV out at a price we set. It would function much like RVShare in that would-be RVers reserve one of the RVs we have in our fleet and come pick it up. The RV would be ready to go with a full tank of water, full propane tanks, and a generator.
Once they return the RV, it gets cleaned and prepped for the next renter. Profits from the rental would be shared with the RV owner.
There you have it. I'd love to hear your thoughts and I hope to be sharing more of these in the future.
When I was in high school, I used to think computers were for nerds. I was a skater obsessed with chasing girls with no time for computers.
It wasn’t until a buddy of mine convinced me to take a Visual Basic 6 class with him, that I realized that I was one of those “nerds”.
Quickly, I fell in love. The first “app” that I ever completed was a game that raced various animal sprites found online using a random number generator. We all placed actual bets on the outcomes of the races. Even the instructor got involved.
That was almost 16 years ago. It’s hard to believe how much has changed. Now I just build gambling apps on the blockchain instead of VB (I’m kidding, sort of).
No real point to this story other than that I’m reflecting today on my career in computing. I’m so grateful for that friend who introduced me to coding and I’m so grateful that this career path exists.
I hope you know how lucky you are too.
Rates are a weird thing and chances are, yours are too low.
I spent years stressing about rates. I would always start strong and but then eventually get talked down (usually by myself).
I think rates go hand in hand with impostor sybdrom. “Why would anyone pay me that much”. It took me quite some time to over come this, however after many years, and multiple rate hikes, we are doing more business than ever.
Raise your rates, now. You are worth it.
People often tell me things like "it must be nice to work for yourself”, or “I'm working hard to make someone else rich".
Having spent many years working for a company prior to starting my own, I can honestly say I would never want a boss again. However, I that doesn't stop me from frequently daydreaming about just how nice that would be.
The idea that having someone tell you what to do, give you a set schedule, allow you to clock out at the end of the day all sound so liberating. Contrast this with potentially long (unpaid hours), angry clients, flakey employees, and surprise tax bills, working for "the man" doesn't seem all that bad.
There's obviously another side to this coin as well. I even wrote a whole post on this topic.
I guess what I'm getting at is, the grass truly is greener on the other side. Working for yourself has its advantages, but there are also some clear benefits of working for someone else. If you want to work for yourself, do it, if you are happy and fulfilled in your job, great.
The only way to lose is to continue down a path that no longer brings you joy.
A few years back, when the company was growing particularly quickly, I made a decision to hire my friends. Although, I had been warned by many others that this was a bad idea, I was sure that I was going to do things differently.
I was going to have a management layer over my closest friends and then they could have the uncomfortable conversations should they arise.
Needless to say, this strategy worked for a time, however at some point, things got tough and I had to make some serious decisions. I had to lay-off my buddies.
This was one of the toughest few months of my life. There was hurt and heartache all around despite my (and their) best efforts.
Working with your friends is absolutely great, until it’s not. We were all fortunate to make it out on the other side and are closer than ever, however things could have easily swayed in another direction.
So, please don’t ignore the advice that I did. Keep your friends and business separate, you will all be much happier in the end.
If you are a mobile developer in 2018, and are not consulting (at least on the side), you are missing out on a huge stream of revenue.
In the early days of mobile app development (2008/2009), it was fairly easy for an iOS or Android developer to get a gig with large companies (Food Network, ESPN, huge list of other names…). At that time, mobile was so new, that none of these companies had internal resources to support this budding vertical.
Throughout the next few years, mobile would sky rocket and all of these companies would hire internal teams to support their products.
This shift caused a huge disruption for mobile agencies who in the previous years were turning down $200+/hour because they simply didn't have the capacity. Many of them had to downsize or close their doors altogether. I was a part of one such company and have seen these shifts during the past 6 years of running mine.
I now believe the cycle is coming back around as there is a need for good mobile developers. The truth is, mobile is hard and there is a lot of competition in the space. Companies are discovering that they can't just hire a "full stack" dev and tell them to build a quality mobile app. It requires a lot of dedication and understanding of the ecosystem. Also, many of the small-medium consultancy in the space have since closed their doors. So supply is down and demand is way up.
I do however feel that the way in which consultants engage with companies has changed a bit. In previous years, most companies were interested in consulting teams / agencies to build their entire solution for them. These days, a "staff augmentation" model seems to make more sense.
In this model, consultants specializing in a vertical of mobile join other teams that lack a particular senior resource. This is a win-win for everyone as a consultant can attain consistent work and a company can hire temporary developers to solve their current problem at hand with no long term commitment. As a mobile developer, if you establish enough of these relationships, you are set on work for the foreseeable future.
We have seen this model play out many times over the past couple years and it has been key (for us) in surviving in this “post-agency” time of mobile app consulting.
So, if you are a mobile app developer (and are particularly good), I'd encourage you to branch out and try your hand at consulting. It's a great time.
I have been obsessed with Seth Godin lately. I've been reading his books, listening to his podcasts, and devouring his blog posts.
It's amazing how he can just pump out wisdom day after day and speak so articulately on just about any subject. Some of his posts are incredibly insightful while others might seem like a small thought that just popped into his head. He doesn't seem to differentiate the two and that's incredible.
Recently, I was inspired by a particular post called The First 1,000 Are The Most Difficult. In it, Seth talks about blogging every single day. He even links to other readers/bloggers that took on the same challenge. This particular quote really stood out:
Even if no one reads your blog, the act of writing it is clarifying, motivating and (eventually) fun.
This got me thinking. I often want to create blog content because I absolutely love writing. Not to mention, I really do feel that I can speak more clearly and articulately having blogged consistently. However, I often won't publish posts (or even start them) for fear of people actually reading them. It's usually a worry about what others might think about the post, or fear of peers/clients reading into things that might be tangentially related to the article in which I'm posting.
So, all that being said, I want to try to blog more consistently. Hopefully once per day. That obviously might mean quality of posts might go down for some posts, but hopefully it will increase overall as time goes on. My wife and I have recently been blogging weekly on our site about our School Bus Conversion and it's been a total blast. I'd love to apply some of that here and talk more about consulting, the business of app dev, etc…
Blogging should be for the author first and foremost, as a way to communicate their thoughts and sharpen their own skillset. Not to mention, it should be fun! I am going to try and embrace this and re-discover my love for writing.
So feel free to subscribe, unsubscribe, or drop me a note. I'd love to check out the blogs of others who are blogging near daily. Cheers!
Seth Godin recently discussed in an episode of the Tim Ferris Show a fear many of us have of the future. He used the example of him landing speaking gigs in which he was more apt to compromise and take gigs he didn’t particularly want on months in which no gigs were currently booked.
As someone in the consulting space, I can absolutely identify with this. In the past, I have taken clients in knowing very well that they will mostly be problematic (funding, difficult, or otherwise). This was out of fear that work might dry up any minute. I know this fear is unfounded as work has consistently come in over the past 6 years of running my company, however sometimes it still creeps in.
Do you deal with this kind of fear. If so, how do you overcome it?
I just had a realization that I’m a professional dream crusher. Being in software consulting, I hear multiple pitches every single week for all sorts of different software. While it’s not necessarily my job to tell people what’s good and bad, I feel it’s my responsibility to at least give them all of the information I can.
In my many years of doing this, I have learned a bit about what works and what doesn’t and I have gotten pretty good at saying no to projects that I don’t believe in. This often means crushing the dreams of someone who has a product idea that keeps them up at night. I always try to be encouraging and present them with some solution, however often times after having a discussion with me, folks will not go forward with their product development.
I often wrestle with this and wonder if it’s my role to help protect these folks by sharing my thoughts or adopt a philosophy of “the money is green either way” and accept their project. I’d be curious if others had this same challenge.