If you ever visited my home, you would know I have a trove of 1980s Atari computers and game console parts stacked on a wall. Besides the nostalgia of that time in my life where my brother, cousins, and friends spent hours around the TV playing games (and programming!) I honestly hope that Atari has a second life.

The unit purportedly is priced below $300. Still no release date, but as the article I’ve linked to states, at least this isn’t a 3D rendering of a prototype.

Here’s a typical scenario that you might recognize. Your boss sends you an email about an issue in the production environment. You research the issue and immediately find that there is a fast way to fix it, but it is kinda/sorta like a hack and you’d eventually have to refactor it in the future if you wanted to extend the functionality of the feature. You study the problem some more, and realize there is an opportunity here to add more functionality for the users of your product while fixing the issue your boss sent you – the problem with this approach is that it will take at least a week longer than your quick fix. You may have already intuited that there is a third option, which is between the first two I mentioned – industrialize the quick fix but it will take longer to get into production by several days.

Many times in my experiences I’ve found out, ex post facto, that a junior developer will opt for the quick fix band aid. This is one way how fragility and technical debt get injected into the codebase. Similarly, you will find that some seasoned developers will choose the option with the longest implementation time to market because they are driven to create the best possible solution they can – and let everyone know that it has to be done perfectly if it’s worth doing at all.

What developers fail to recognize here is that management has to weigh in the balance multiple competing agendas. A few that come to mind are: customer experience, breakage, and prioritization. The customer experience is something everyone in the company should be interested in. For this particular issue your boss told you about, you should without being asked, try to find out the volume of the issue, and the run-rate. In other words, when did the issue happen, and how many times a day / how many users a day does it affect? Once you quantify the issue, a severity can be gleaned from the results. If the volume is high and impacts revenue then that’s what breakage means. (I tried to find a good definition of breakage but Google kept pushing hair product results at me???) Breakage can be thought of as opportunity cost but that’s not technically correct. You’re not giving the user an alternative you’re removing a an opportunity because the feature is broken. Lastly, if there are high priority features that must wait while you repair existing features that might jeopardize the timeline and release date of the pending launch.

Using empirical metrics calculated by debug logs or sales figures will quickly help you ascertain what the priority of a quick fix is. If the breakage is small or (if you’re lucky) zero, then you can wait until a scheduled release and opt for an industrialized fix or potentially the “Boy Scout fix” which is the second option outlined above. If you respond to your boss quickly with data that supports your recommendation you will have hopefully scored big with her because she will notice you have anticipated business questions and delivered a menu of choices that have accompanying data to lend credence to your conclusions.

The seedy underbelly of the internet is home to denizens of the dark – spammers, the “darknet” black market warez sites, illicit porn. Today we’ll shine a bright light on a technically illegal but incredible consumer of yours and my time – unsolicited commercial email spammers. You might drop by the friendly website at Spamhaus and read their definition of spam. According to them, spam must be both unsolicited and bulk. Unsolicited is self-explanatory, but bulk deserves a one liner: a bulk email is one that was not hand written. It’s a form letter blasted out to a mailing list where key fields such as name and job title have been dynamically inserted (think Wordstar mail merge!)

Sample email where the SPAMMER couldn’t figure out their spam software:

My name is {!User.FirstName} {!User.LastName} and I am your local Regional Director here at SignalFx. I would like the opportunity to meet with you and discuss your current Infrastructure monitoring and Application Monitoring. We will only take about 30 to 45 minutes. I know that your time is important so we would be glad to do this over lunch or happy hour if that works better for you.

SignalFx is the most advanced monitoring and alerting solution for modern infrastructure and applications. Our mission is to help cloud-ready organizations drive high levels of availability and performance in today’s elastic, agile, distributed environments.

Since I have a LinkedIn profile, and because companies such as the one I work for commonly use an easy to crack pattern for email address name conventions, I get inundated with spam. I get about a dozen new spam emails a day. Let me take some time to tell you why I despise spam with such a visceral hate. It interrupts my work momentum. I have to read my email for a large part of my day. When I find myself scanning the boiler plate salutation sent from a spambot site such as Marketo or ConstantContact (née ConstantSpam) it derails my train of thought and I find myself instantly angry at the distraction.

On occasion, I’ve interacted with the spam authors who crank the spam out from their spam factories day after day. I’ve received several nice replies however the mainstay is rudeness, bitchiness, and worse. Here are the three reasons they send me spam. They want to sell my company something and they don’t care what my role is. I’m an application developer manager. Why the fuck would I want to read your sales pitch about PMI Certification? Clearly, spammers think I control the budget for all of IT as well as I’m snowed under by requests for QA, DevOps, training, and of COURSE consulting services. I’m inundated by requests to hire everyone from every consulting agency. If the account managers who blast out their spam only knew that I receive about 50 NEW emails from agencies a week they would realize that I would have time for little else if I read every spam email and sent a reply back. I get that they’re trying to generate a sales lead, but when all of your competitors cold call and send spam, how are you different? How on earth do you think you will be heard?

One thing I’m thankful for is getting rid of my work phone. I used to get a cold call every other hour on some days…I’m not exaggerating. Because of the selfish nature of business – every salesman for himself – these account reps do not care that they are interrupting me. They want a sale. After getting rid of my work phone you would likely not be surprised to know that somehow my personal mobile phone number started to ring about once a month. I tracked down the online scum agencies that do this and threatened them with legal action and got the info removed.

Conference calls are a necessary evil. Many times you find yourself working with consultants who are contracted to complete a project that your company doesn’t want to hire dedicated people to build and you need to work with them smoothly to complete the project. What I’ve noticed about conference calls, and meetings in general, is a lack of basic understanding of how to best use everyone’s time and what to do to get the best experience out of the meeting.

Have an agenda. I mean, this one is a no brainer. A written, bulleted point agenda does wonders for letting people know if they even want to participate in the meeting or not. Time is incredibly valuable and you want to make sure everyone maximizes the time spent.

Invite only people who will contribute. Do you find when you invite people that they in turn forward it to 5 other “friends”? Those extra people show up and either play with their phones or play on their laptops the entire meeting without contributing anything. What they’ve done is cheapen the meeting as well as not being productive at their own jobs.

If you are the one on the phone, or if there are multiple parties on the phone, learn to respect the rule of the conch, meaning : shut up and listen every other sentence. There is nothing worse than having someone drone on and on without letting someone else interject a question, correction, or some other thought. You might as well record your soliloquy and email everyone the YouTube link versus a conference call.

Keep conversation at a high level unless you are working on a specific incident or issue. This one takes context – sometimes you’re working on a specific issue…again, see #1. Why would you keep things at a high level? Well, you’re not going to solve world peace in 30 minutes. Parceling out todos, giving an update on an issue and maybe 1 or 2 other material things is all you should hope to accomplish.

Choose a conference method that has good audio (even better, video). So much time is wasted figuring out logistics.

Are you screen sharing? If so, ZOOM IT so that people on the other end can see what you’re sharing. They’re not looking at a 5K retina Steve Jobs miracle screen most likely.

At the risk of hubris, I want to give you benefit of my experience. Through the years I’ve boiled down the essence of how to excel at your job. No, really I have. Your job doesn’t have to be an application developer for what I’ve distilled into what I call my “Mantra for Success”. A mantra is speech consisting of something sacred, something holy, something that you hold dearly.

Let’s first reveal what my mantra is and then we’ll break it down. Here it is.

Are you:

Thinking holistically?

Following up?

Being proactive?

Acting professionally?

What does thinking holistically mean? Holistic means that the whole is more than the sum of its parts, which is a synonym for another fancy word: gestalt. Many times holistic is an adverb and most of the time gestalt is a noun based on context. Essentially, what this translates to into the work environment is, “Are you aware of how the thing you’re working on affects other things as it relates to the rest of the system?”

Let’s say that you made a change, a small change, to an existing stored procedure for an application that you’re building. This new change is adding a new, un-defaulted parameter to the stored procedure interface. You check in the change and the next week you release both the stored procedure change and your shiny new application that consumes the stored procedure change to production. Immediately your email inbox starts buzzing with frantic calls to find out what was just launched in production that broke the main mothership website that funds your paycheck. It turns out that your change broke the main website! It was because you didn’t think holistically about what impact your change would have on the rest of the system. If you work in a big, disconnected codebase, then you know what I mean when I say that, “upstream problems become downstream concerns.”

That was an anxiety ridden part of the mantra to start off with, wasn’t it? The next one is less dramatic but possibly key in getting your next promotion. When you work on a team, and you have a task assigned to you that requires cooperation with someone on another team, does that scenario fill you with dread? Do you immediately feel that this will be a harder task merely because of the coordination required? You should. Because it does make any task harder. You steel your resolve, work on your part of the task, and then send an email (or update a Jira task to “blocked”) to the other team member who needs to take the baton you are handing off to them so that the task can be completed. You go on your merry way through your work day taking the next task off of your queue and working on it, thankfully one that doesn’t require anyone else’s help.

A week goes by and on a Tuesday after a holiday weekend, your boss sends you an instant message urgently requesting your butt in his office. He interrogates you about that task that you finished YOUR part of that you then handed off to someone else. He tells you that the person who was supposed to work on it was on vacation for the last week and the task wasn’t completed. What’s worse is that the task was to create an onsite discount on a partner’s site to target the holiday weekend that had just passed by! Oh noes! What just happened? You did YOUR part. Why do you feel uneasy then? You should feel uneasy if you don’t. You didn’t follow up with the other person. You didn’t investigate to understand if this was something that needed to get released to production by a certain date. Were there other failures present in this scenario? Sure, but let’s focus on YOU. It’s not your boss’s job to follow up – it’s EVERYBODY’S JOB TO FOLLOW UP.

At the restaurant I worked at for 10 educational and formative years of my life, there was a sign on the wall in the back of the kitchen, out of site from the customers. It read, “It’s not my job. $1 penalty.” If you were caught by management saying those words “It’s not my job” then you had to put a dollar in a jar. Every so often management would buy “guilt cookies” with the proceeds and everyone would get to enjoy the laziness of others in a satisfying and illustrative way.

On the tail of the previous mantra segment is a closely related one: proactivity. You know what I’m going to say, don’t you? Being proactive could mean many things, but let’s take the Boy Scout tact for a moment. Allow me to link to another blog because he does a great job talking about the Boy Scout rule. If I had to fit it on a bumper sticker, I’d write, “Always leave things better than you found them.” Simple enough?

You’re at work (again!) and you are working on fixing a bug in some of the code. While you’re analyzing the code, you find that a string operation is being performed in a piece of code in the same file as the bug you’re working on. This string operation is concatenating a string by adding to an existing string in a loop, sometimes up to thousands of times. You know that this is a very expensive (in a CPU consumption fashion) piece of code. What do you do? Do you rewrite the string operation code? Do you only fix your assigned bug? “No good deed goes unpunished” as the saying goes…why should you do more work than you need to? Well, because if everyone does a tiny bit of extra work when they edit the code, eventually the entire system gets better. That’s thinking holistically AND being proactive.

I could write many more real and fictional anecdotes to illustrate this point but it should already be evident that being proactive means more than simply “doing more”…you’re anticipating a future need based on historical precedent (always supplying source SQL with a report that you send to your boss, for example, because he asks for it EVERY SINGLE TIME you omit it) or you are presciently supplying more than was asked of you.

Professionalism. You haz it? You might think you have it but you don’t. The longer you’re in the same role, the longer you’re at the same company, the older you get, somehow your professionalism erodes. You have to have some professionalism in a certain measure for it to even begin to erode, mind you, so this is an assumption on my part (remember what Mrs. Falbo in Tiny Town said about assumptions, don’t you? (fast forward to 4:45)). I’ll tell you, there’s nothing that will get you kicked out of your job faster than being UN-professional. Have a major interpersonal meltdown in an open area at work? Yell at a customer? Lie, cheat, steal? This part of the mantra is the foundation for your career. You must be professional at all times. Don’t lose your cool or you might lose your job. Serial apologists, please show yourselves to the door – being penitent ex post facto is courageous and self-effacing but your coworkers and boss will quickly tire of repeated incidents of acting out.

Well, this is the beginning of something, that really started in 1980 when I received my first computer, the Timex Sinclair 1000. Wow, what a piece of shit, but I sat in front of it every day and typed in programs and saved them to tape. I bought a chess program and when it crashed half way through a game (the computer was kicking my ass btw) I tried to debug it. Although I couldn’t find the error, I started to understand how complicated software can be.

Soon, I was writing little programs on my own such as a nifty robot that walked across the screen. Mind you, the Timex Sinclair was a 32 column black and white glorified calculator, but I wore the membrane keyboard out with my experiments. Life complications intervened for a few years after that and I didn’t get a better computer until 1984 when I bought an Atari 400 with some summer money saved by painting houses and soon after that, my restaurant career. I’ll never forget the feeling and sense of accomplishment that came from my first program executing in front of my eyes though – I had caught the programmer bug.

I won’t bore you with my atypical childhood and pursuit of programming and education – each of us has our own story in that regard – instead I’ll set the table for what this blog is about and my intentions for its use.

I plan on blogging about interesting technical problems that I have and will encounter while working at my day job, which is a developer manager at Match.com. My background is heavily Microsoft (thanks Bill!) but I am trying to get up to speed on MacOs and iOS development using BOTH Objective-C and Swift. I will tag my posts correspondingly to the tech involved. I have no illusions or delusions about any fame or acclaim generated from these future pithy posts but it I end up helping others by sharing a technique, gotcha, or best practice (sometimes Stack Overflow just doesn’t cut it) then it’s a win in my book.