The World of Jay Little
The Manifesto of a Productive Business Software Developer
11/3/2015 12:28 PM
The other day I got asked by my boss' boss to share the "secret sauce" behind my productivity at work. This was an odd moment for me as over the last 17 years of my of professional life, nobody has ever asked me to do that. But it did get me thinking about it and that has led to me making a few notes on the subject that I've decided to share with the world.
  1. Get intimate with your code base.
    All too often the developers I work with only have a skin deep knowledge of the product they are tasked with augmenting and supporting. This will only hurt your productivity in the long run. One of the reasons I like to take on as much work as I do when I start some place new is so that I can get familiar with the code base that I'm going to be working with. The bigger the code base is, the more commitment you'll need to come to terms with it.

    Nevertheless, developing an understanding of how things work in a code base will heighten your ability to change how things work in that code base. It will also allow you to fix bugs in a more efficient manner as well as reduce the risk of you creating new bugs. Take the time to explore and dig deep when you are working on something in an unfamiliar section of code. Don't get hung up on the "could haves", "would haves" and the "should haves". The code base is what it is. Bitching won't fix it. Only good old fashioned incremental hard work has a snowball's chance of pulling it off.

  2. Your customer expects timely results.
    In my experience those results usually manifest in the form of releases and updates. On a longer running project you may fall back to demos and test environments as a way of showcasing progress. Nevertheless, every day should result in measurable progress on any problem you are spending time solving. Remember we are business software developers and business isn't content to wait for the "nerdery" to get its shit together.

    This advice becomes even more prudent when faced with bugs. Bugs are defects in the prior work you have delivered to a customer. Defects cannot be tolerated. If you receive a bug report for software that is in production or software that is about to go to production, resolving that bug report should be your absolute highest priority. Co-workers have marveled at and criticized the zeal I display when I get into bug hunting mode. The truth is that I consider bugs to be a sign of failure and wiping them from existence is vital for my mental health, at least for me. Obviously your mileage may vary here.

  3. Don't get caught up in ivory tower bullshit.
    In our industry it is all too common to hear people rattle on about the latest "design pattern", "testing framework" or "development methodology". Here's a bit of truth for you: I don't know a single design pattern. I simply don't give a shit. As far as automation goes, I believe that at best it offers some limited value in particular situations, but I'm by no means a convert. My only development methodology is this: "Release good software in a timely manner".

    Obviously this advice flies in the face of certain principles that guide our profession. But you aren't going to stand out by following the herd like some kind of sheep. If you want to be a better developer, you've got to focus on the results. The best way to do that is to stay focused on the problem that your customer has tasked you with solving. Be sure you have taken the time to properly define that problem up front. Remember that regardless of what new technology or concept comes along, software developers were solving business problems long before it came along. While we scoff at ancient languages like COBOL or even old fashioned procedural programming concepts, the reality is that "It's a poor craftsman that blames his tools" or so the old adage goes.

    To summarize: If your approach doesn't directly benefit the customer, you are likely doing it wrong.

  4. You are the customer's last resort.
    In other words, treat every issue as if it was something that either you yourself fix or it doesn't get fixed at all. I've spent a substantial portion of my career billing people by the hour for my coding services both directly and indirectly. I've legitimately found myself in this situation many times. This mentality is something that a lot of developers lack in my experience as deep down they know they can just call in the Calvary and get them deal with it. I say that with the full realization that I'm usually the Calvary.

    There is real value in conditioning yourself to rely upon yourself. This doesn't mean you shouldn't ask for help in certain situations but my expectation is that a seasoned/senior developer should be able to produce a viable solution for every single problem they are presented with. It might not always be the absolute best solution, but then again, the job of the rest of us is to lend a helping hand when that situation arises. If you at least take a real crack at the problem and produce a proposed solution before asking for help, you are definitely on the right path here.

  5. Locally test.
    Does this one seem kind of obvious? Good. It should. I've worked with a lot of developers over the years and the dirty little secret that most of them share is that they don't locally test their work. They just code and deploy. Once I had a co-worker at a previous job compliment me on the motivation I displayed for getting our application running locally because "nobody else here has it setup locally". I was literally floored. That means all of the other developers aren't testing their work before they push it. That's absolutely ludicrous in my mind.

    This extends to bug fixing as well. When I receive a bug report, the first order of business in my mind is to try and replicate that bug in my local environment. Once I can replicate the failure, I can verify the fix. None of this is rocket science. When it comes to quality in software development I've found over the years that you either put in the time up front, or you'll put ten times as much effort into fixing the bugs after the code goes into production. Do you really want to skimp on this up front? I sure as hell don't.
To finish up, I'd like to offer up a caveat of sorts. Regardless of the advice that I provided, at the end of the day practice makes perfect. My father handed me my first software development book at the impressionable age of six and let me goof around on the family Apple IIe with it. That's where I got my start. If you do the math, since I just turned 36, that means I've been writing code for around 30 years now. It started off as a hobby but for the last 17 years it's put bread on my table. The long and short of it is that I've been doing this a very long time. Longer than most people seem to realize. I'm a firm believer that when children are taught skills and consistently develop those skills throughout the course of their life, they typically become masters of those skills.

In any event, I've found that the best way to improve a particular skill is to keep using that skill and employing a reasonable level of self criticism. Given enough time and effort, your skills and productivity will only improve short of a severe mental blockade of some sort. Bottom line: Keep on keeping on.
The Day Facebook and American Cloud Computing Died
10/28/2015 12:46 AM
The day has finally come. Today I have been forced to disolve my relationship with Facebook. Why? In a single word: CISA. In a nutshell CISA is a piece of legislation that allows companies like Facebook to more freely share customer data with the government. All data shared with the government (DHS) under the auspices of this law is automatically shared with the FBI and the NSA. Even more importantly, customers have no recourse against this data sharing as the corporations in question will be immune to lawsuits which touch upon activities covered by it and the process itself is specifically exempted from the Freedom of Information Act.

What does that have to do with Facebook? Well beyond the fact that Facebook can make use of these loopholes once it becomes law (which is an eventuality at this point as similar versions of the bill have now passed the House and the Senate and the White House supports it in principle), Facebook has been privately lobbying for this bill to be passed while publicly remaining quiet about it. This makes sense when you consider that the government's first attempt to pass this same bill a few years ago was met with stiff public opposition on the internet and eventually was scrapped as a result.

As a result of this revelation and today's passage in the Senate, I will be moving my social media presence exclusively to Twitter. Now let me preempt the catcalls by explaining this move in greater detail. To put it simply, the information I put on Twitter is for the public and it has always been that way. This expectation hasn't ever changed. Whereas in the case of Facebook it used to be a place where there was a clear boundary between the data you shared to the general public and the data you shared amongst your circle of friends. Over the years that distinction has been eroded to the point where every few months you've got to go back and scour your privacy settings after Facebook "updates" and wipes out whatever settings you had set prior to that point.

This is essentially a bait and switch tactic and I have remained complacent about it for far too long. Facebook's support of CISA is the straw that has broken the camel's back. It is unforgivable and cannot be ignored. While the rest of the country rages against conspiracy theories regarding their second amendment rights and the imminent scaling back of those rights, the reality is that ever since 9/11 our fourth amendment rights have not only been assaulted, but substantially reduced. Between the Patriot Act, CISA and the numerous ongoing violation of my fourth amendment rights being perpetrated by the NSA each and every day, the days in which I can foolishly and implicitly trust the US Government are long since over.

The real problem here is that this law arguably represents the beginning of the end of American based Cloud Computing as educated customers can now safely assume that any data they share with American based Cloud Providers is also being shared with the US Government. As an employee of a cloud based services provider I find this to be exceptionally disturbing. As a potential customer choosing between multiple cloud providers, being an American company was already a black mark in my eyes. After this, being an American company is akin to being a kiss of death.

Keep in mind that despite claims to the contrary, this law won't do anything to bolster the security of our information. The primary reason is the most obvious one: This is a reactive law, not a proactive law. It basically allows the government to easily acquire a copy of any and all information stolen after it has already been stolen. How does this information help the government to keep us safe from the bogeyman? It doesn't really. It's just a convenient way for them to exploit the situation and gain access to information that they may or may not have had access to before. The reason the government supports these kinds of laws is simple: They have prioritized getting access to information over protecting information from being accessed by unauthorized parties. This is why the government overtly pushes for backdoors to encryption. Such tactics weaken the security of all affected parties and make them easier targets for everybody: Including the government.

Back on topic: To be fair, Twitter is American based, but as I pointed out before: When I tweet something it is meant for the world at large. There were never and are no current expectations of privacy for that information and I'm good with that. The situation with Facebook is different: It was supposed to be about connecting with and communicating with your friends. However based on the story told by their actions over the last few years, there is no legitimate expectation for privacy at Facebook now.

Goodbye Facebook. I'd say it was nice knowing you but the fact is that you were probably more trouble than you were worth. Anybody interested in following me and communicating with me can either email me, subscribe to the RSS feed for this site or just follow me on twitter @BigJayLittle.
Search:   [Rss]   [Email]