Brandon Trebitowski

  • Programming Languages Are Only Tools

    Some young punks overheard me talking about JavaScript at lunch today. They felt it necessary to come to my table and tell me “typescript is waybetter”. They don’t realize that this sort of thing screams “I’m a junior developer! I know very little about the tech industry!”

    If you are a newer developer, learn early that you are greatly limiting your potential by marrying a subset of programming languages. You will greatly increase your value by being open to learning and building in any language that is best suited for the project.

    I try to convey this to the students of our boot camps all of the time as boot camp students are the most likely to call themselves “PHP/JS/WordPress/etc developers” and not understand that there is a whole world out there beyond what was taught in camp.

    Ok, rant over. Get off my lawn.

  • Dev Blinders - Failing To See Things From A User Perspective

    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.

    The Moral

    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.

  • Tips For Starting Your CS Career

    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!

  • No One Cares About Your Clever Code

    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.

  • Prototypes Usually End Up In Production

    “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.

  • Client Deliveries Are Hard

    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.

  • It's A Good Time To Be A (Good) Mobile Developer

    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.

subscribe via RSS