CategoryArticle

The Mind State of a Software Engineer

T

Have patience.

Coding is discovery. Coding is failing. Be ok with this.

*image reference

Don’t blame the framework. It’s more probable it’s your code. Accept this fallibility.

*image reference

Know when to walk away. You mind is a wonderful tool, even at rest it’s working on unsolved problems. Rest, and let your mind do it’s work.

*image reference

Be comfortable not knowing. Software engineering is a vast ocean of knowledge. Someone will always know more than you. The sooner you are OK with this the sooner you will recognize the opportunity to learn something new.

*image reference

Anger and frustration don’t fix code. Take a break, nothing can be accomplished in this state.

*image reference

3 Reasons Why Code Reviews are Important

3

A great code review will challenge your assumptions and give you constructive feedback. For me, code reviews are an essential part in growing as a software engineer.

Writing code is an intimate process. Software engineers spend years learning the craft of software engineering and when something critical is said of our creation it’s hard not to take it personal. I find myself, at times, getting defensive when I hearing criticisms. I know the reviewer means well, but this isn’t always comforting. If it wasn’t for honest feedback from some exceptional software engineers, I wouldn’t be half the software engineer I am today.

Benefits of Code Reviews

1. Finding Bugs

Sometimes it’s the simple fact of reading the code that you find an error. Sometimes it’s the other developer who spots the error. Regardless, simply walking the code is enough to expose potential issues.

I think of my mistakes as the grindstone to my sword. To quote Michael Jordan:

I’ve missed more than 9000 shots in my career. I’ve lost almost 300 games. 26 times, I’ve been trusted to take the game winning shot and missed. I’ve failed over and over and over again in my life. And that is why I succeed.

2. Knowledge Transfer

Sharing your work with others is humbling. In many ways you are the code. I know that I feel vulnerable when I share my code.

This a great opportunity to learn from and to teach other engineers. In sharing your code you are taking the reviews on a journey, a journey into the code and aspects about you. A lot can be learned about you by how your write code.

At the end of the code review the reviewers should have a good understanding of how the code works, the rationale behind it and will have learned a little bit about you.

3. Improving the Health of the Code

As I mentioned, the more times you read the code the better code becomes. The more reviewers the better the chance one of them will suggest an improvement. Some might think skill level matters, it doesn’t. Less experienced software engineers don’t have the deep technological knowledge as experienced software engineers, but they also don’t have to wade through all the mental technical baggage to see opportunities for improvement.

Code reviews gives us the benefit of evaluating our code. There will always be something to change to make it just a little bit better.

Coding, in this way, is much like writing. For a good piece to come into focus the code must rest and be re-read. The more times you repeat this process the better the code will become.

In Closing

Some companies don’t officially do code reviews, that’s ok. Seek out other engineers. Most software engineer’s will be happy to take 10 to 15 minutes to look over your code.

5 Steps for Coding for the Next Developer

5

Most of us probably don’t think about the developer who will maintain our code. Until recently, I did not consider him either. I never intentionally wrote obtuse code, but I also never left any breadcrumbs.

Kent Beck on good programmers:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Douglas Crockford on good computer programs:

It all comes down to communication and the structures that you use in order to facilitate that communication. Human language and computer languages work very differently in many ways, but ultimately I judge a good computer program by it’s ability to communicate with a human who reads that program. So at that level, they’re not that different.

Discovering purpose and intent is difficult in the most well written code. Any breadcrumbs left by the author, comments, verbose naming and consistency, is immensely helpful to next developers.

I start by looking for patterns. Patterns can be found in many places including variables names, class layout and project structure. Once identified, patterns are insights into the previous developer’s intent and help in comprehending the code.

What is a pattern? A pattern is a repeatable solution to a recurring problem. Consider a door. When a space must allow people to enter and to leave and yet maintain isolation, the door pattern is implemented. Now this seems obvious, but at one point it wasn’t. Someone created the door pattern which included the door handle, the hinges and the placement of these components. Walk into any home and you can identify any door and it’s components. The styles and colors might be different, but the components are the same. Software is the same.

There are known software patterns to common software problems. In 1995, Design Patterns: Elements of Reusable Object-Oriented Software was published describing common software patterns. This book describes common problems encountered in most software application and offered an elegant way to solve these problems. Developers also create their own patterns while solving problems they routinely encounter. While they don’t publish a book, if you look close enough you can identify them.

Sometimes it’s difficult to identify the patterns. This makes grokking the code difficult. When you find yourself in this situation, inspect the code, see how it is used. Start a re-write. Ask yourself, how would you accomplish the same outcome. Often as you travel the thought process of an algorithm, you gain insight into the other developer’s implementation. Many of us have the inclination to re-write what we don’t understand. Resist this urge! The existing implementation is battle-tested and yours is not.

Some code is just vexing, reach out to a peer — a second set of eyes always helps. Walk the code together. You’ll be surprised what the two of you will find.

Here are 5 tips for leaving breadcrumbs for next developers

1. Patterns
Use known patterns, create your own patterns. Stick with a consistent paradigm throughout the code. For example, don’t have 3 approaches to data access.

2. Consistency
This is by far the most important aspect of coding. Nothing is more frustrating than finding inconsistent code. Consistency allows for assumptions. Each time a specific software pattern is encountered, it should be assumed it behaves similarly as other instances of the pattern.

Inconsistent code is a nightmare, imagine reading a book with every word meaning something different, including the same word in different places. You’d have to look up each word and expend large amounts of mental energy discovering the intent. It’s frustrating, tedious and painful. You’ll go crazy! Don’t do this to next developer.

3. Verbose Naming
This is your language. These are the words to your story. Weave them well.

This includes class names, method names, variable names, project names and property names.

Don’t:

if(monkey.HoursSinceLastMeal > 3)
{
    FeedMonkey();
}

Do:

int feedInterval = 3;

if(monkey.HoursSinceLastMeal > feedInterval)
{
    FeedMonkey();
}

The first example has 3 hard coded in the if statement. This code is syntactically correct, but the intent of the number 3 tells you nothing. Looking at the property it’s evaluated against, you can surmise that it’s really 3 hours. In reality we don’t know. We are making an assumption.

In the second example, we set 3 to a variable called ‘feedInterval’. The intent is clearly stated in the variable name. If it’s been 3 hours since the last meal, it’s time to feed the monkey. A side effect of setting the variable is we can now change the feed interval without changing the logic.

This is a contrived example, in a large piece of software this type of code is self documenting and will help the next developer understand the code.

4. Comments
Comments are a double edge sword. Too much commenting increases maintenance costs, not enough leaves developers unsure on how the code works. A general rule of thumb is to comment when the average developer will not understand the code. This happens when the assumptions are not obvious or the code is out of the ordinary.

5. Code Simple
In my professional opinion writing complex code is the biggest folly among developers.

Steve Jobs on simplicity:

Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.

Complexity comes in many forms, some of which include: future proofing, overly complex implementations, too much abstraction, large classes and large methods.

For more on writing clean simple code, see Uncle Bob’s book Clean Code and Max Kanat-Alexander’s Code Simplicity

Closing

Reading code is hard. With a few simple steps you can ensure the next developer will grok your code.

A Simple Guide to Finding Your Next Job

A

It’s time to look for the next job, eh? I feel for you. Finding a job sucks. It’s one of those things that everyone must do at some point. I equate it to looking for love. Every aspect of “you” is on display. When someone passes on you, it’s hard not to take it personally. Chin up my friend; we’ll get through this.

Who am I? Good question. I’m a software consultant, I’ve had three jobs, on average, each year for the last four years. I’ve been on both sides of the table in hundreds of interviews. I’ve learned what works and what does not.

1. Your Resume

Before you start applying for jobs a good resume is a must. A resume speaks to who you are and what value you offer an employer. Your resume is your ticket to an interview. In fact, the sole purpose of a resume is to get an interview.

This is so important; I need to repeat it: “The sole purpose of a resume is to get an interview.”

Resume Tips
There is always an urge to fib a little, who will know, right? Don’t lie on your resume. I’ve interviewed candidates who padded their resume with skills without knowing how to explain or perform these skills. I’ll add a caveat and say that your resume needs to be a simple read. If you held a position called System Analyst III, which had the responsibilities of a Senior Software Engineer then change the title to Senior Software Engineer otherwise, a prospective employer would decipher your job titles instead of checking your qualifications.

Compare your resume to the job description. Make sure your resume is a good fit for the position. Sometimes this might require moving some items around on your resume to highlight the desired skills for the position.

A little statistic: On average, a hiring manager will look at your resume somewhere between 3 and 15 seconds. Make that time count!

Keep Your Resume Updated
Even when not looking for a job, it’s good to update your resume. When the time comes to hand out your resume, you won’t be left trying to remember your accomplishments.

Your Resume’s Presentation

Chefs know presentation. A meal that looks unappetizing, regardless of taste, goes uneaten.

Make you resume visually appealing. It needs to be clean, consistent and well structured. It might behoove you to hire a designer. You want your resume to standout from the rest. Be mindful of the audience. A graphic designer’s resume looks entirely different than a database engineer’s resume.

2. Getting an Interview

Your resume is polished. It’s time to start applying for positions.

I start with the following sites:

Dice
This is my go-to site for technology-related positions. Recruiters or companies will see your resume. The downside to a large job site like Dice is recruiters will inquire about positions outside your geographic area or they will inquire about positions not matching your skill-set.

Careers Stackoverflow
This is the cream of the crop. Companies posting positions on Careers are looking for the best and the brightest. I’d pay close attention to these companies.

Craigslist
This is a hit or miss. Some of the postings are good; others are not. It’s still worth a look. You might find a great opportunity.

Indeed.com
Indeed searches many companies and job sites. They discover jobs not usually found on other popular job sites.

Linkedin
If you are not a member, sign up now! It’s the Facebook of the professional world. There is a search that will return positions not found on the other sites.

Friends and Family
Put the word out with your friends. You’ll have more credibility if you are recommended by someone the hiring manager already knows. I put a signature at the bottom of my emails stating what I do and how to contact me.

Cold Calling Companies
I’ve never done this, but if you have time on your hands why not?

Recruiters
Companies tend to hire agencies to find upper-level management or highly technical candidates. It’s good to check with a recruiter if possible build a relationship with a couple of them.

Finding the right job takes time. It’s not uncommon for the search to take a couple of months or even a year. Don’t get discouraged. Take a temporary position if you must, and do your best to keep your skills sharp while you keep looking for a permanent position in your field.

Recruiters are sales people. Their job is to convince you to take the position. Recruiters will try to talk your rate down. It’s their job! Be ready for it.

Know Your Value
Know your value, go to salary.com or glassdoor.com to find the rate of compensation in your area. I have friends who make over 200k a year. When the market says, they should be making 100k a year. How do they do it? They know their value and stick to their guns when pressured. On the downside, occasionally a position is lost. Someone who needs a position might not want to risk losing an opportunity. Taking a lower rate might be the best thing for your situation. This is something only you can determine.

Know What Positions You’ve Applied To
Track where you have applied, it can benefit you in two ways. First, applying to a position twice gives the appearance of an unorganized person and second, you can follow up with companies where you’ve applied.

3. The Interview

Congratulations! You have an interview!

The interview is the most important part of the job hiring process. It’s also the most nerve-racking. To have a successful interview, confidently articulating your ideas is a must. This is, of course, easier said than done. Being prepared will help immensely. This starts with knowing your resume inside and out. Expect questions on every aspect of your resume. If you are nervous in interviews, practice interviewing in front of a mirror or with a friend.

When responding to questions, make your answers concise. If you don’t know the answer, don’t waste time talking about something you don’t know. An interviewer can spot this a mile away. Instead, simply say “I don’t know”. Sometimes you may have an educated guess, share this with the interviewer.

Interviewing is a two-way street. The company is evaluating you. Use this time to do the same. Always put together a list of questions to ask during the interview. The list should include questions on their development process, the position’s responsibilities, the project, the work environment and the company policies (i.e. hours, telecommuting, etc.). The aim is to walk away from the interview with an understanding of the company, the position’s expectations and the goals of the project.

Unfortunately, sometimes your best just is not enough, there are candidates out there that are better qualified (i.e. more education, more experience…, etc. ). There is nothing wrong with this. It happens. Don’t let it get you down.

Following Up
Most companies will give feedback within a couple of days. If you don’t hear from them within a week, reach out to your contact and inquire about the status of the position.

In Closing
Searching for a job is challenging. It may take many interviews to land the right position.
When you do not see the results you expect, don’t be afraid to change up your strategy. Most importantly, stay positive. This can be hard at times, especially when you receive rejection letter after rejection letter. When you do finally land the position, it will be worth it.

When are you a Senior Developer?

W

When I hear “Senior Developer” I think of someone who has mastered programming. I think of a person who can design, code and test a system. They can talk to system architecture or component design. They understand and use design patterns. This person can anticipate the performance bottlenecks, but knows not to pre-optimize. This person will leverage asynchronous programming, queuing, caching, logging, security and persistence when appropriate. When asked they can give a detail explanation of their choice and the pros and cons. In most cases they have mastered object oriented programming and design, this not an absolute other languages such as javascript, F#, scheme are powerful and are not object oriented at heart. They are adept in risk management and most important of all they can communicate the before mentioned to their peers.

What is mastery? There is a generally accepted idea, that to master ANY one skill it takes 10,000 hours of repetition for the human body and mind to grasp and internalize a skill. This is written to at length in Malcolm GladWell’s book Outliers.

Some examples of in Malcolm GladWell’s Outliers are:

Mozart his first concerto at the young age of 21. Which at first seems young, but he has been writing music since he was 11 years old.

The Beatles were initially shunned. They were told they did not have the mustard and should consider a different line of work. They spend 3 years in Germany playing about 1200 times at different venues, each time being 5 to 8 hours in length. They re-emerged as The Beatles we know and love today.

And lastly, Bill Gates at age 20 dropped out of Harvard to found Microsoft. To some this might seem foolish, but considered at 20 he had spent nearly half of his young life programming. In 1975, only maybe 50 people in the world had the experience he did. His experience gave him the foresight to see the future in Microsoft.

Peter Norvig also discusses the 10,000 hours rule in his essay “Teach Yourself Programming in Ten Years”.

In the book Mastery by George Leonard, great detail is given on how to master a skill. One must practice the skill over and over and over again. The more the repetition, the more you become aware of the differences in each repetition. Only with this insight can you become better.

The software industry’s titles (Junior, Mid-Level and Seniors) are misleading and inconsistent from organization to organization. I’ve worked with companies, who defined a Senior Developer as someone whom had 5 years or more of experience. There is not mention to the quality of the experience, just that they have sat in from of a computer for 5 years. In working with these folks many of them had not yet grasp object oriented programming, yet they were considered Senior Developers.

There must be a better more objective way to measure the skill set of a software engineer. John Haugeland has come up with a computer programmer’s skills matrix. It’s gives a common, objective way to measure a programmer’s skill level, which otherwise is left mostly to gut feeling.

When looking at software engineers I see 4 tiers of skills: Luminary, Senior, Mid-Level and Junior.

Liminary (10+ years) is one who has mastered a skill and has set about improving their respective discipline. Some examples include: Ted Neward, Uncle Bob Martin, Donald Knuth, Oren Eini, Peter Norvig, Linus Torvalds. This is change depending on your skill-set.

Senior (7 to 10+ years, Level 3) is one who has spent the last 10,000 hours programing in a specific genre. There is a strong understanding of design patterns, They leverage asynchronous programming, queuing, caching, logging, security and persistence when appropriate.

It’s very possible that a Senior will never reach Liminary. Liminary’s are often found speaking and writing. They are actively trying to impact their discipline.

Mid-Level (4 to 6 years, Level 2) is one who understands day to day programming. They work independently and create robust solutions. However they have yet to experience creating or maintaining large or complex systems. In general Mid-Level developers are great with component level development.

Junior (1 to 3 years, Level 1) is one who understands the basics of programming. They either have a degree in software engineering or computer science or they are self taught. Their code is continually reviewed. Guidance is given in regards to algorithms, maintainability and structure.

About

Chuck is an experienced software consultant creating technical solutions using ASP.Net Core, Angular 2+, React, the cloud (AWS and Azure), Docker, application architecture, agile (SCRUM, Lean), and performance tuning. Chuck lives in Folsom, California with his lovely wife Erin and their tabby, Mango.