CodeOverEasy.com

Category: Musing

Letters to junior developers

Dear Recent Graduate or Entry Level Developer,

As someone who has been in the field you have selected for your career for some time, I hope you will allow me to offer some (completely unsolicited) advice about our industry. I’ve been where you are: eager, motivated, and hopeful. I’m sure you’ll encounter plenty of people who will have their own version of what I’m about to give you, but take them all together and just maybe something will carry with you in your career.

Do this job because you love it

Software developers like us certainly don’t corner the market on passion for our jobs. But with passion can come great results. I heard early on in my career the suggestion to “find something you love so much that you’ll do it for free, then become so good at it that anyone will pay you to do it.” These days (compared to when I was in your position) being a programmer is a lot more trendy and mainstream. Those who have passion will sustain – those who are just on the bandwagon will likely flutter off to some other interest.

Learn to communicate

Software is a unique product in that it reaches out to all levels of business and society. In your job, you’re inevitably going to encounter customers, managers, and clients who may be executives and directors. I’ve found that most of the time, particularly when things are not working as they should, these people want answers, not deep technical explanations. Consequently, you need to learn to communicate effectively to lots of different audiences.

One key element of learning to communicate is knowing how to balance discussion on technology and business. Since in most cases, business rules the day (see below) you want to be able to engage with someone about their business, and also explain technology and its capabilities for them. Sometimes this is as simple as asking “Would you like me to explain how this works?” rather than assuming they want to know.

Additionally, effective communication comes by knowing and understanding the perspective of your audience. If you are speaking to a business owner or department head, chances are they have a very bottom line view of the world, so you’ll need to learn how to discover those core values and then engage the person in that context. In general, I find you’ll be much more respected, well received, and more likely to be invited back to the table when people feel like you can represent technology without making them feel overwhelmed or lost.

Business rules the day

With extremely few exceptions, you are going to work for an business. That business is measured by a very simple equation: revenues minus expenses equals profit. Some organizations pretend that they are about other things, like serving people or changing the world. But in truth they are measured by money.

You will be hired to either increase revenues, decrease expenses, or facilitate both. These two objectives will drive every decision, every meeting, and every opportunity that you will face.

However, many of us (myself included) enter the industry without really understanding how business works. We arrive, eager to write code and make something, never thinking that every hour we spend stuck on an issue is costing the company something.

Therefore, I encourage you to get a basic education in business principles. Understand the core principles of accounting. Know how your employer keeps score, that is, what are the revenue centers, what are the cost structures, and how does your effort directly affect the bottom line. To that point – know what the phrase “bottom line” really is talking about!

You will inherit someone else’s code, and someone else will inherit yours

In my parent’s generation, a worker would often stay with one company for their entire career. In my generation, and likely for yours, this is no longer the case. If you are on the same project or with the same company for more than 3 years, you may be the exception. As such, the code you write and the code you are assigned will have lots of contributors to it.

I say this because inevitably, the code you inherit will suck. It will drive you crazy. It won’t make sense, and you’ll long to be inside the head of the person who wrote it just to figure out what the hell they were thinking. And then someone will feel exactly the same later on in life with the code you write. If there ever existed an unspoken courtesy among programmers, it should be to try to make life easier for the next developer on the project. This is at its simplest a longwinded way of saying “put comments in your code.” But in the same way you’ll appreciate receiving those explanations, the ones who inherit the projects you have worked on will thank you.

Learn to do things right, not just make them work

One of the most cringeworthy statements I hear from developers on my teams when they get faced with a problem is something along the lines of “I just had to hack something together…” Hack jobs are ticking time bombs. A great deal of technical debt in the world is the result of hack jobs, done in a hurry, because someone didn’t want to take the time to do it right. Resist this temptation as diligently as you can.

If you feel caught between a problem and a deadline – go petition for more time. Most managers and customers are reasonable enough to understand that a quick fix is often a seed that grows in to an expensive problem down the road. Learn how to communicate that risk.

Present a solution, not just a problem

Finally, as a manager, you need to understand that I’m busy. My day is full of lots of things. So if you get stuck or have a crisis, just telling me about it adds one more thing to my plate. Here’s the better way to do it:

If you have a problem or are stuck on something that needs your manager’s attention, come prepared to explain the problem to them but also present your solution. Let me know that you’ve put some thought to this. You can ask for either my clearance to go do your plan, or a validation that your plan is reasonable and feasible. But most importantly, demonstrate to your team or management your ability to solve the problem, and it won’t go unnoticed.

Being a developer is a great job. It’s fun, rewarding, and will provide you a good living. I know it has for me. Go forth and code!

Photo credit: Jeric Santiago

January 22, 2015
CodeSpaces and the risk of cloud computing

I love small business. They innovate. They drive our economy. They offer products in an agile manner.

I love cloud computing. It’s convenient. It’s flexible. It makes things affordable that once were cost prohibitive.

Doing business with anyone carries risk, and some may feel that doing business with small businesses carries greater risk. But we do it anyway because we like the product or service that is offered.

One such small business that I have done business with is CodeSpaces. They were a startup that provided cloud-hosted Source code control such as Subversion and Git. They had a continually improving project management dashboard oriented around agile methodologies. They were affordable, with plans as low as $2/month.

When I started HomeSpot HQ, I had a laptop. I did most of my development on that laptop, but knew I needed a place for source code control. Being familiar with Subversion, and being in need of a free or low cost solution, I researched and found CodeSpaces. Upon registering for an account, I pushed my source files in to the cloud, ready to access them anywhere.

CodeSpaces announced yesterday that their service had been breached by an unauthorized attacker, and that a good portion of the code, project information, and other customer data that had been willingly pushed to the cloud by their customers had been irreversibly destroyed.

CodeSpaces issued this statement about the incident:

Code Spaces will not be able to operate beyond this point, the cost of resolving this issue to date and the expected cost of refunding customers who have been left without the service they paid for will put Code Spaces in a irreversible position both financially and in terms of on going credibility.

As such at this point in time we have no alternative but to cease trading and concentrate on supporting our affected customers in exporting any remaining data they have left with us.

Thankfully for myself and for HomeSpot HQ, I had moved off of using CodeSpaces for my ongoing source control solution. But had I not, then not only was CodeSpaces’ business compromised, but quite possibly mine would have been as well.

I frequently receive emails from new HomeSpot HQ users that read something like this. “I really love your product and am excited to use it. However, what happens to my data if you disappear as a business? Is there a way to export or extract it?”

These users are rightfully being proactive in considering the safety and trustworthiness of the cloud. They recognize the value of the data they would provide, and the value of the time required to provide it. They want assurances that their effort will not be wasted because we close up shop overnight.

CodeSpaces is the victim of a crime. They indicate in their full statement that they have withstood previous attacks without incident. It is unfortunate that this crime leaves the company in a state where their only option is to close.

This story (and many like it) illustrate the risk we take when using hosted services. It forces me as the provider of such a service to redouble my efforts to keep my customer’s data secure. This is the world we live in.

Photo credit: https://www.flickr.com/photos/carbonnyc/

June 19, 2014
Is Scratch the future of programming? Do we want it to be?

A few weeks ago I took my six year old daughter to a Scratch workshop at our local public library. I had heard about Scratch, but had not really seen it in action, and was very curious to see how my kid would take to it.

The workshop leader gave a very brief intro to the platform and did a simple sample program to get us started. He also had printed out the learning cards from the Scratch website, which give various samples and the specific code blocks to use to complete them.

By the end of the hour, we had implemented and adapted the program from one of the tutorials to make a picture of a cat chase a picture of a fish, and play a ‘meow’ sound whenever it ‘caught’ it. My daughter had a lot of fun, and now has added ‘can I play Scratch’ to her list of tech related requests, after 1. Can I watch a movie? and 2. Can I play on the iPad?

For those who may not be familiar with it, Scratch is a project from the MIT media lab. There is a great TED talk about its origins. The user interface is at the same time kid friendly and sophisticated.

Programming in Scratch involves selecting a sprite and assembling a list of commands by dragging-and-dropping them on to a program canvas. The commands are color coded, and snap together Lego-style. You can have multiple sprites, and all the basic programming constructs are there, including conditions, loops, variables, events, and properties.
While Scratch is one of a growing number of platforms intended to introduce children to programming, it makes me wonder if it is the future of programming. Given that a whole generation of kids may grow up using Scratch, and consequently think that programming is a drag-and-drop, snap-together experience, I wonder if they will be disappointed to know that in real life, programming is a lot of typing.

I have a lot of respect and admiration of Andrew Hunt and David Thomas, authors of The Pragmatic Programmer. One of their tips is simply “Write Code That Writes Code”. They liken code-generators to templates and jigs used by woodworkers to use for repeated tasks. In some regard, Scratch is a code generator, in fact, quite a dynamic one. The click-together code blocks abstract out the core usage into a simple UI based entity, suitable for even a 6 year old to comprehend.

As a professional developer, I have always had a love-hate relationship with code generation tools. Part of me is a purist, wanting to write and own my own code, line by line. Part of me sees the HTML generated by Microsoft Word and wants to throw up. I have always held that writing code and gaining the experience and understanding of what is really going on is more valuable than just getting something generated quickly. But would I be happier to be able to quit typing line after line and instead drag-and-drop blocks on to the canvas? Would I feel in control enough of the output to appreciate the simplicity and convenience that the canvas offers?

A more tangible analog to Scratch in the physical world are SnapCircuits. This ingenious kit allows kids to design and assemble electronic circuits and systems using snap-together components that conduct electricity through the contact points. There are switches, batteries, lights, bells, capacitors, and resistors. Using a underlying grid, you simply assemble the circuit by placing and connecting the individual parts. All the realities of electronics are there, just in a kid-friendly mode. Ohm’s law holds true for SnapCircuits just as it would any other electrical system.
But would you wire a house using SnapCircuits? Would we want to, given the chance? Wrapping wires around screws has worked for decades, right? Are these ‘snap-together’ systems only suitable for children?

If a system or new code-writing methodology would let me as a developer build systems faster, then there certainly is value to that. But are we too ‘mature’ to consider ‘kid-friendly’ methods as the way to achieve those gains? Perhaps my daughter’s generation will demand that shift, and they’ll have the bright minds at MIT who created Scratch to thank for it.

October 14, 2013
Teaching kids to think (not just program)

There’s been a lot of emphasis lately about teaching kids about coding and programming. There is an entire course on Pluralsight on this topic. There’s a viral video from Code.org featuring celebrity CEOs, engineers, and even athletes, which opens with the following quote from Steve Jobs:
Everyone in this country should learn how to program a computer…because it teaches you how to think.

School districts around the country have rewritten their mission statements with more orientation towards “technical literacy” or “becoming citizens of a digital world”. And high tech breeding grounds like MIT have produced tools like Scratch that enable kids to create online, story-based games.

As a developer myself, I find myself often thinking about my six year old and the world in which she exists. She has on-demand access (via Roku) to her favorite movies and shows. She is drawn to our iPad like a moth to light. She walks through the grocery store chatting on a pink toy cell phone. Her world is awash with technology. It’s all she has ever known.

So when I ponder the question myself of whether or not to teach my kids how to program, I think Steve Jobs got it backwards. I don’t believe we should encourage programming in order to teach kids to think. I believe we should teach our kids to think, and let them apply that thinking to programming. Become a brilliant problem solver, then do it faster with the technology. The thinking comes first, then the coding, not the other way around.

The problem with a ‘programming first’ approach is that, especially these days, the answers to the problems come way too easily. We have the internet, for Pete’s sake, which is a repository of other people’s solutions to problems. Programming first orients the objective around completing the program, rather than placing the proper emphasis on thinking your way through a solution.

Here are a few of the practical ways I am trying to encourage problem-based thinking around our house:

1. As much as I can, when I do a home improvement project, I invite the kids to participate. In this context, we’ve dealt with topics like geometry, electronics, and physics. I don’t expect them really to remember (at this age) how we used the Pythagorean theorem to check if the raised garden boxes were square, but it exposed them to a method to solve a specific problem. If you’re really up to it, make them the stars of their own DIY video.

2. Put problems in the way of them getting what they want. I am in the process of planning a scavenger hunt to find clues to get the unlock code for the iPad. If they want to open it up, they have to solve the puzzle. The hope is that they tie together the motivation of getting what they want with the process of following the clues.

3. Talk to them about what makes the technology they love work. I am frequently asking them questions about how they think the games they play know how to keep score, or how the episode of the cartoon du jour ends up on the TV. Their answers will amaze you, and it creates a teachable moment to encourage them to think of their own game or create their own methods.

4. Try to not go to the Internet first when they ask a question. This one is hard, because it is so easy to just use the Google to get a quick answer. We have lots of books in our home, and as often as I can, I try to point to non-digital sources to satisfy their curiosity. It helps them learn to look things up, and prevents the addiction of instant gratification from taking hold.

As a parent, part of my challenge is balancing the exposure with the benefit. We try to limit our kids to a fixed amount of TV or iPad each day, knowing that without this limit, they would undoubtedly consume it morning, noon, and night. Yet I have to consider what worlds they would explore or create if they had unrestricted time.

Computers and coding changed my life. They became a passion, a career, a livelihood. They may or may not do the same for my kids. But far more critical than them following in my chosen career path, I want them to know how to face tough problems in life, and think their way through them.

Photo credit: http://www.flickr.com/photos/dumfstar/

August 26, 2013
Lessons from my first radio interview

This month I had the privilege of being a guest on a the Home Toolbox Radio show to discuss HomeSpot HQ and home maintenance in general. Since this was my first experience I thought I’d share a few of my own “lessons learned”.
Prepare your remarks, but don’t assume you’ll use them

When we were coordinating the interview, it seemed appropriate to prepare some specific talking points. I had a document ready that had questions and answers. In reality, the interviewer conducted the discussion much more casually, and so the prepared answered were all but unused.

Your involuntary verbal ticks will naturally come out

In listening to the recording of the interview, I was embarrassed to hear how often I used the phrase “you know” as I gave my responses. It is complete unconscious to me while I am speaking (you know?). Try to prepare yourself to become hyper-sensitive to these phrases so that you will be able to catch yourself and minimize how frequently you say them.

Find a good room

Since the radio show was in Ohio, I called in as the guest. Since I have children, the last thing I wanted was for one of them to burst in to the room and interrupt while I was on the air. Solution? I locked myself in the bathroom. However, it may not have been a good choice given that it had both vaulted ceilings and lots of hard surfaces that create echoes. The walk in closet may have been a better option since it was both smaller and the clothing would have helped reduce echo.

Be confident

Chances are you’ve been asked on the program because you’re considered an expert on the topic at hand. When you boost your own confidence in your responses, they will come out clearer and more concise.

You can listen to my radio interview below.

Photo credit: http://www.flickr.com/photos/varresa/

June 13, 2013
Why are you lying to me Mr. Progress Bar?

As long as there have been computers that do work, there have been various forms for communicating progress to the user.

I find these often to be a bunch of lying liars.

When the bar fills up, the operation should be complete. If it’s not, then don’t fill up the bar.

Here’s the dialog that prompted this post. It is the installer of a Visual Studio update. The bar is filled up, but clearly there is more work to be done.

Web usability expert Jakob Nielsen writes about acceptable response times for actions done by a computer in his book published in 1993!

In cases where the computer cannot provide fairly immediate response, continuous feedback should be provided to the user in form of a percent-done indicator [Myers 1985]. As a rule of thumb, percent-done progress indicators should be used for operations taking more than about 10 seconds. Progress indicators have three main advantages: They reassure the user that the system has not crashed but is working on his or her problem; they indicate approximately how long the user can be expected to wait, thus allowing the user to do other activities during long waits; and they finally provide something for the user to look at, thus making the wait less painful. This latter advantage should not be underestimated and is one reason for recommending a graphic progress bar instead of just stating the expected remaining time in numbers.

To their credit, the Visual Studio team did provide a sprite so there was some motion while the installation took place. But contrary to Nielsen’s suggestion, a filled up progress bar did not “make the wait less painful.” It just plain irritated me.

In the same way that developers should make their error messages meaningful, the status reported out to users should be useful and convey accurate information.

Photo credit: http://www.flickr.com/photos/jacksonmedeiros/2719799718/

May 8, 2013
Find a happy place

There are certainly more stressful jobs than being a software developer. Still, there are unique pressures that come with the territory when working to ship a product, support a product, or (in my case) serve a client and their systems.
Let’s face it, when dealing with technology, or sometimes end users, we can often feel like Peach from Finding Nemo under attack from Darla.

Finding your own happy place is an important part of being a successful worker, developer, parent, and person.

Stress management comes in all forms. For some it is a quiet space, a book, and hot tea. For others it may be an intense workout at the gym. Still others may find a simple walk around the office park to be enough to clear the mind and refresh one’s thinking.

For me, it is lunch by the lake.

Near my office is a country club that has a lake. Along that lake is a road. And along that road I will park my car and eat my lunch.

Sitting by the lake gives me a chance to get perspective. Whatever broken code or failed install or bizarre client request befalls me is safely tucked back at the office. Across the lake I can see people playing mid-day tennis. Around the corner, a lucky few are teeing off in their round of golf.

The lake is a reminder that there is more to life than work.

Coming to and from the lake is a motivator, as I pass by country club homes with luxury sedans parked in their driveways. I believe working hard will reap benefits, and pressing on through whatever the day’s stress may be will inevitably teach me something.

What is your happy place? Do you go there often enough?

April 9, 2013
Replaceable parts and software design
This past weekend I replaced the brake pads and rotors on my car. It took a couple hours, cost about $90 in parts, and left me not just with a sense of achievement and personal satisfaction, but a with lots of thoughts about how mechanical systems work, how standardization should function, and how these things translate into the world of software design and development.

The aftermarket auto parts industry is huge. In my area, there are at least 3 national brand auto parts retailers. They stock thousands of parts for hundreds of makes, models, and versions of automobiles. They can do this because of standards. A brake pad for my vehicle can be made by aftermarket manufacturers because they can develop against a standard, ensuring the part will fit and perform as expected in my car. Most of these aftermarket brands boast how they “meet or exceed the original equipment manufacturers standards…”

As an end user of my vehicle, if I am so inclined, I can perform the task of replacing worn out parts with new parts. I can do this in many cases without any particular training or expertise, or the need for specialized tools. I simply dismantle and remove the old part, and install the new part. And most of the time, it just works.

But when was the last time an end user could replace a broken block of code with a different block from another manufacturer?

Never? Rarely? Oh, silly man, that’s not how software works!

I concede, a hunk of metal is a lot different than code that can contain logical or programmatic errors. If the metal wears out or doesn’t perform, we just cast another one and put it in its place.

There are a few key points that emerge in this discussion.
- Ownership versus Licensing
- Open versus Closed Source
- Software aging and reuse
Ownership vs. Licensing

When I purchase an automobile, I (or the bank) own it outright. There may be a manufacturer’s warranty in force, but the manufacturer has no claim to the tangible asset. It becomes my property, and I am largely free to do with it what I want.

Software is a different animal because it is a licensed product. In the majority of cases, what I buy when I purchase a piece of software is permission to use the product, not the product itself. For example, here is the first clause from the OS X Mountain Lion license agreement (emphasis mine):

1. General.
A. The Apple software (including Boot ROM code), any third party software, documentation,
interfaces, content, fonts and any data accompanying this License whether preinstalled on
Apple-branded hardware, on disk, in read only memory, on any other media or in any other form (collectively the “Apple Software”) are licensed, not sold, to you by Apple Inc. (“Apple”) for use only under the terms of this License. Apple and/or Apple’s licensors retain ownership of the Apple Software itself and reserve all rights not expressly granted to you.

Thus, by agreeing to the license, I have no right or authority to modify, enhance, customize or otherwise repair the code. I must take it as is, trusting that it will work as expected. If it doesn’t, I am at the mercy of the producer to deliver a patch. Otherwise, I’m stuck.

(Note: for a far more educated perspective on this topic, I recommend the Freedom to Tinker blog by Princeton University professor Ed Felton.)

Open Source vs. Closed Source

The advent of Open Source software in the late 1990s challenged this traditional form of licensing by opening up the ability to view, change and customize the code covered by the license. Still, most commercial software is closed source and tightly guarded by its licensing terms. My ability to modify the functionality of the product is limited to the configuration settings or integration points exposed by the creator.

Software Aging and Reuse

Generally speaking, software doesn’t wear out. The code written 10 years ago, given a suitable runtime environment, should still work. A one is still a one, and a zero is still a zero. Unlike my brake pads, which degrade every time they are used (albeit ever so slightly), software code does not break down with each subsequent execution (unless of course it was designed to do so.)

Most software improvements and future versions are created to add features and repair bugs. In some cases, producers may rewrite products from the ground up in order to take advantage of the available tools, hardware specs, and methodologies that are in play at the time. But the old code, left as is, doesn’t stop working just because it is old and has been used repeatedly.

So if software doesn’t wear out and is not mine to modify, is there a comparison to the replaceable parts of my car? I still think so.

Designing for change

Software in its own way is purposefully rigid. You want it to do one thing well. Until you don’t. At that point you want the flexibility to make it behave differently. And if you are so inclined, you’d love to do it yourself.

Not all products do this because designing in that kind of flexibility takes more time, costs more money, and requires more effort.

The best example I know of such a product is the very tool I am using to share these thoughts. WordPress has a pretty amazing capacity to accept add-ons from 3rd party developers. As an end user, if I want my blog to have advertising, or my Twitter feed, or be an ecommerce site, I don’t have to wait until the WordPress creators add these features as officially sanctioned behaviors. I simply add a plug in. If the first one (or ten) I check out don’t do it the way I want, I have more to select from. If all else fails, I can write my own.

The internet browser is another class of software that is becoming more modular. Whether they are called ‘add-ons‘ or ‘extensions‘ or ‘accelerators‘, they all serve to let me as the end user tweak and adjust how the product works.

Perhaps these plug-ins are more akin to putting a new stereo in my dashboard to replace the factory installed unit than they are to replacing a worn component.

Designing modular, extensible software can be a challenge. I believe though that there are certain advantages to do so, particularly for consumer products. Now it’s time to press software creators for more of that freedom.
April 5, 2013
The Internet thinks I am 5 years old.

In the early days of the good old World Wide Web, the emerging anonymity was often summed up with the cartoon “On the Internet, nobody knows you’re a dog.” published in 1993.

Now, 20 years later, not only does the Internet know you’re a dog, it knows whether you’re a mutt or a purebred; whether you like rawhide or stuffed squirrels; and if Eukanuba ends up in your online cart more often than Iams. Our digital trail is captured on every purchase, every tweet, and every wall post.

Many online services use this history to ‘aide’ me as a consumer. Amazon may have been the first to pioneer a robust recommendation engine based on past purchases. But now services like Netflix, Pandora, Facebook, and even my local newspaper’s site all make attempts to pique my interest based on whatever they know about me.

And quite frankly, they suck at it.

It’s not that they don’t properly analyze the data. It’s that they allow the data to be polluted. And in my world, the biggest polluter of my digital persona is none other than my kindergartner.

I have had a Netflix account since 2008. I have probably watched a few hundred movies and TV episodes. In 2010 I got a Roku, and my Netflix account became more accessible, allowing me to dial up Mythbusters or Top Gear whenever I wanted and watch on my TV. Shortly thereafter, however, a shift occurred. Suddenly, my recommendations started looking like this:

and

To their credit, Netflix has announced they will be introducing “personalized profiles” in the near future, undoubtedly in response to an endless stream of emails from fathers who, in fact, don’t have an interest in Tinkerbell or Babar they way Netflix thinks they do.

My internet persona is becoming an amalgam of my entire family. We have one Amazon Prime account, under my wife’s email. So as far as Amazon is concerned, she not only likes theology books, but also electronics gear and tech books. Polluted. But why would I pay another $80 a year to have my own Prime account?

We experience the same challenge with our recently purchased iPad. In many ways it is a ‘family’ device, used by mom, dad, and kids alike. But it’s my iTunes account associated with the device, so Apple is left to believe that I like Hay Day and PBS Kids as much as I like Evernote and CNBC.

The problem of ‘householding’ isn’t new. Just ask any direct mail business or non-profit who gets separate donations from husband and wife. But you want to believe that we are getting better in this technological age. Unfortunately, the progress is slow.

While I wait, I guess I’ll enjoy another Feel Good Talking Animal show.

March 26, 2013