Postcards From My Life

Dear Reader,

Developers love shiny things. We love to play with new toys, try out new APIs, and libraries. If it was featured on Hacker News, we will find a way to shoe-horn it into a project, just to say we used it.

Therein lies one of the problems with developers.  In our race to implement the shiny, we rarely stop and answer the question “Just because you can, should you?” The answer is obvious to us, “Yes, I should BECAUSE I can!” This is a perfectly acceptable answer for personal projects. Heck, that is what personal projects are for.

In production systems though, careful thought should be put into each and every library you bring into the system.

• Is it absolutely necessary?
• Is it the best tool for the job?
• Do we have a reasonable level of confidence in the code?

Look at why the library or project was created? Was it created for systems like yours? Was it created for systems that operate on a similar scale as you? This is commonly known as “You are not Facebook.” If a project or library was created for Facebook so that facebook can solve a problem at the scale they operate, it is most likely a very bad fit for your project unless you operate new the same levels of scale.

Sometimes, the shiny is the right answer and you use it and everybody is happy. That’s great, as long as you’ve done the research to prove that it is the right answer.

Spending more time thinking about the goals of your project will help you spend less time chasing the shiny.

Until next time,
I <3 |<
=C=

Dear Reader,

Q: What is the best way to convince a potential employer or client that you can do the job?

A: Show them that you have already.

Every developer should have a public portfolio of code that they have written and can explain. That last part is important, we will talk about it in a second.

You should have a profile on a social coding site (I like GitLab.org) with examples of your code and real-world projects you have created. “Coding Examples” are great, usually these are highly polished pieces of code. Developers take the time to make sure they meet relevant coding standards, demonstrate knowledge of current best practices, and generally just show off. This is great and you need these in your portfolio.

You also need real-world examples. In the real world, compromises have to be made, you can’t always do it the right way, sometimes you have to do it “the only way that works”. That is what potential employers/clients want to see. They want to see that you can make the hard decisions and trade-offs when necessary.

When you do make those trade-offs, you need to be able to explain and defend them. You need to be able to articulate the why and not just show the how. This lets the potential employer/client know that it was a conscious decision and not just blind luck.

Make sure your body of work showcases the real you, because that is what they really want to hire.

Until next time,
I <3 |<
=C=

Dear Reader,

Every since “Social Coding” became a thing and GitLab and that other social coding site opened up, developers around the world have been asking “GitLab or LinkedIn for my CV/Resume?”

I now present you with the definitive answer to this question.

YES

Github, or your favorite social coding site is absolutely necessary for a developer. You have to have a profile and you have to have some public examples of your code that potential employers can look at.

Hiring managers look at your work and look for things like

• Advanced concepts (depending on the level of job you are applying for)
• Coding style
• Style consistency
• Application of Best Practices

They may also pick out one or two bits of code to discuss with you in the interview.

• Why did you code it this way?
• What were the requirements of the project?
• Did it cause you any unintended consequences?

Your answers help them understand how you code. Your entire social coding repo will help them understand you are a developer.

There is more to you than your ability to code, though. Your social coding profile can’t show everything. That’s why you also need a traditional resume/CV.

Your LinkedIn profile shows things that your social coding profile cannot. Things like:

• Career Progression
• Time at each job
• Range of companies you’ve worked for.
• Extra curricular activities (e.g. hobbies)

All of these are just as important as your social programming profile.

Show potential employers that you are a well rounded software developer by making sure you have both a social coding profile and a LinkedIn profile. Help them discover this by cross-linking them.

Until next time,
I <3 |<
=C=

p.s. yes, it has occurred to me that Microsoft owns both LinkedIn and that other social coding platform.  Kinda scares me a little.

Dear Reader,

A while back I wrote I love writing code! in which I talked about the fact that am not ashamed of the fact that I love writing code. Software development is my passion and I am blessed enough to be able to do it for a living. The other side of that coin is I am not my code. I am must more than a professional code monkey.

These days I

• Attend my church
• Date my wife
• Mentor my kids
• Help build the PHP community by speaking at conferences and user groups
• Shoot my pistols
• Scuba Dive and help others learn to Scuba Dive
• …and much more

I am a much more rounded person than just a software developer, and that’s a good thing. Yes, my passion is still writing code and yes, there are nights when I’m up at midnight still tweaking that last little feature. (I’m getting old, it used to be 2 AM) But I do so much more.

It is OK to be passionate about software development but you will be doing yourself a favor if you cultivate an interest that is away from your keyboard. Not only will you put yourself in a different environment, you will work with people that do not have a computer-centric point of view. This reason alone makes it worth the effort. You will be amazed at how different the real world is once you get out of your tech bubble.

Get out from behind the computer and beyond the keyboard; get out there and get a life!

Until next time,
I <3 |<
=C=

Dear Reader,

1. Fins in FIRST
2. BCD next with the jacket open
3. Place your regulator in the jacket and then close the jacket over it.
4. Wet suit goes on top
5. Zip it up

I run this mantra about once a month with fresh new minds learning how to scuba dive. See, there is a right way to pack a wet bag, this way. At the lunch break, I am always happy to discuss the why with the students, but during class, the why is because I said so. I’ve got 350+ dives. I have made every non-fatal mistake that a diver can make. Additionally, there are thousands of divers all over the world that have tried every new idea you think you have for how to pack a wet bag and guess what, we all have standardized on this way because it is the best way. That is why we teach it as the right way.

For the past few years in tech, the prevailing attitude is “everyone should learn to code”. (that’s a whine for a different day) I believe that everyone interested should learn to code, but if you are going to learn, accept that there are right ways to do things and wrong ways to do things. In scuba diving, doing things the wrong way usually has pretty immediate and sometimes disastrous results. In software development, your ‘new way’ might work well for years. But doing things the wrong way will  eventually lead to a failure.

Please, on your own personal project, experiment all you want. Do things any way you want as long as you are the only person who will ever have to use or maintain the code. If there are other developers involved though, do things the right way. Do things the standard way, follow the community standards for the code you ware writing. If we all do this, everyone wins.

Until next time,
I <3 |<
=C=

p.s. We pack a wet bag that way to protect the regulator and console.  That is the most sensitive and usually the most expensive piece of dive gear. Fins are sturdy and cheap, they go on on bottom to protect everything from drops. Wet suits are soft and spongy. If something gets dropped on your bag, the wet suit helps absorb the blow. There is a reason we call it the right way.