Postcards From My Life

Dear Reader,

There are people I trust, and others I do not. Who I trust largely depends on the context of the conversation. For example, if we are talking crypto-currencies, I trust my friend Luke Stokes. He has proven to me time and time again that he understands the domain-space and has earned my trust.

When it comes to programming, Robert (Uncle Bob) Martin is a trusted source for me. You are welcome to espouse any opinion on programming that you may have but if you disagree with Uncle Bob (and you are not someone like James Gosling) then no, I will not trust you. If you do it often enough I’ll learn not to trust you at all.

Our world increases it’s dependency on software each and every year. I trust those who have studied it, who have learned it, and who have a proven track record of doing it right over someone who  has not; experience matters. If I am having open heart surgery, I want the most experienced doctor doing it. Not someone who has 5 years experience and has developed a new way of doing it. (Let them experiment on someone else) :)

It’s not a matter of respect – I can be respectful to both parties, even the one I disagree with – it’s a matter of earned trust.

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

p.s. if probably goes without saying but if you dn’t trust me, ignore this blog post. :)

Dear Reader,

Free advice is worth every penny you you pay for it.

I recently had a good friend of mine run an idea by me. It sounded solid so I told him so. I thought it was a great idea.

He ran it by another friend and they told him it was a worthless idea. This friend had nothing good to say about the idea. This discouraged friend 1 to the point where he was seriously considering giving up on it totally. Hearing this from friend 2 was demoralizing.

Dive with 3 computers

In scuba diving, many professional divers carry three dive computers on each dive, their primary and two backups. Part of this is because you never want to be underwater at depth and have your computer fail. Trust me, it’s happened twice to me. No, the main reason they do it is because If, when they get back to the surface, their primary gives them a reading they don’t expect, they have  backup. Having one backup though doesn’t really help. At that point you have to decide which one you want to go with. In some cases that might make the difference of being able to dive again today and not. That can be dangerous on the life-n-death level. That’s where the third computer comes in. Now you have 3 “opinions”. You can take a consensus and go with the majority. If your primary was giving you a reading you didn’t like (e.g. you went into Deco) but the other two did not, you can feel safe about diving the next dive.

However, if two of the three computers tell you you went Deco, listen to them. It doesn’t matter if you don’t want to hear that. It doesn’t matter if you don’t believe them. You bought the computers – you sought their advice – so heed the advice. 

Applying the rule of 3 to free advice

• Don’t just ask one person, they may lie to you to not hurt your feelings.
• Don’t just ask two because then you don’t know which one to believe and you end up going with the one that you agree with.
• Ask three people. And even if you don’t like the answer, listen to them.

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

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.