Why it’s so hard to break into software developer work

To many people, it seems a weird contradiction. Companies are desperate to find more software developers, yet every quarter there are hundreds of people graduating from coding schools, colleges, and universities who complain about how hard it is to find a job. How can these two facts be true?

Let’s start with the salary. The idea of $80,000 – $160,000 salary is tempting to a lot of people. That money can change someone’s life. But the reason the salaries are so high is that the skills required for the job are tough to build.

Here’s an example that I call the “developer test”: Imagine you’re sitting at your desk trying to solve a software bug. Pressure is on; your manager is asking for reports every hour; customers can’t use the product. It takes you three grueling days of carefully walking through code, looking at change lists and logs. You test theory after theory, and they keep failing. Something  you think is true is not.

At the end of three days, you discover a single wrong character in the code that accounts for everything that was happening. With one keystroke, you fix the bug. In the dozens of cases similar to this that I’ve heard about from colleagues and personally experienced, I’ve noticed a trend. Some people are so excited that they can’t talk about anything else. They’re jazzed up and full of energy the next day: the world makes sense again, and they’ve learned a lot. People who have this reaction are in the right kind of job; it’s likely a good fit for them.

Some people live in fear of the situation that I’ve described. They hate it. They cannot stand combing through code to discover which of their assumptions was false. In my experience, these people are likely to look for a tangential job as a program manager or data analyst, or just leave tech.

This is one of the main reasons that it’s hard to go from freshly graduated developer to professional. The amount of time, energy, and emotion it takes to train someone who doesn’t love the work is far greater. For me, it is much more demoralizing than kind of three-day bug I described above.

This might seem obvious, but if you want to break into software development, it will be difficult if you don’t actually love to program. Between drafts of this post, I’m working on a little side project to convert APIs between the four languages that I normally code in. Coding for fun is a strong indicator that you love what you’re doing. Software companies see a person who loves to code as someone worth investing in.

A second consideration needs to be factored in too. Programming courses are primarily focused on programming. In these classes you might learn variables, functions, loops, classes, and so on. However, there’s a big piece missing from most software curricula that you’re expected to have as a professional developer. When I evaluate a junior developer, I want them to understand Git, Docker, and SQL. Comfort with a terminal and a basic understanding of cloud systems are important for a junior backend developer. Any of these things can be taught, but people who’ve already worked with them are more interesting to hiring managers.

I’ve hired several junior developers, including some who’ve come from non-traditional backgrounds. Here are some of things that I commonly find for strong candidates for those positions:

1. They know how to learn. No matter what job you take as a software developer, you’ll constantly be learning new technologies and tools. Strong candidates demonstrate that they can learn on their own. Writing blog posts or making github projects are good ways to show off.
2. They write code for a purpose. Their side projects have some value to them. For instance, my wife is one of five adult siblings, who all have spouses and children, and they’re spread across four different US states. Every year we use a Secret Santa tool I wrote so that we don’t have to ship out dozens of Christmas presents each. Every year I refine the tool a little to work better and make it easier.
3. Their projects work with 3rd party APIs. Writing your own tools against APIs for gitlab, social media, travel sites, stock sites, and so on is a great way to learn more about networking and how APIs work.
4. They learn about the layers around their focus area. Learning AWS/Azure/Google Cloud is helpful for anyone. Front end and mobile devs will want to understand networking and backend enough to talk about it. Backend devs need to understand databases and hosting.

Breaking into software development is hard. Lots of people want to do it. To be successful, you need to show that being a software developer means more to you than just earning a paycheck. If hiring managers can see your curiosity and love of hard problems, they’re more likely to see you as worth investing time and effort in. Good luck.

Breaking into Software — Factoring Code

One of the best ways to show off your technical knowledge is with Github repositories. (If you’ve never played with Git, check out https://lab.github.com/). Many companies today ask one of their experienced developers to evaluate a candidate’s Github. Often this is done by asking the candidate to submit a homework assignment, but even if they don’t assign you a project, someone likely still looks at your repositories. Unfortunately, this can work against you. To get your repositories to work for you, you need to make sure that your code is well factored.

To understand the basics of code factoring, consider the following basic diagram of webpage.

In this diagram, there are three operations happening: initialization of the HTTP listener, a request over HTTP, and some core logic. This is how the code should be divided up. You want three files: a main file that will do all your initialization, and a file for your HTTP listener, and your core logic.

Why is this important? Because professional development is done by layering more and more code onto the skeleton of your applications or services. The more isolated the functionality of that code, the easier it is to work with. We commonly call this the “single responsibility principle“. When someone is reviewing your code, factoring into files that have each have a single responsibility is one of most common criteria that you’ll be judged on.

Here is a rules of thumb:

• Your main function is a file. Its purpose is to initialize everything.
• Any input, known as ingress, into your application — such as network, screen actions, or direct user input — should go into its own file for the appropriate input type. A parsed config file gets its own file. If you also parse an input CSV (comma separated value), that should have its own file.
• Each type of egress to storage files, databases, or 3rd party APIs gets a file.
• Your core business logic, the interesting part about what your code does, should have its own file.

Most code has the same pieces: you take in data; you store it; you read it back. But there is nearly always a part that’s unique to your problem space. We call this the “business logic”. For example, when you log into your email, there is a part that figures out how many emails to show you initially, using what sort order, and what filter (inbox, spam, and so on). This is the business logic of email. If you have a mobile app and webpage, this part of the code can be shared. The part of your code that you can share should be in its own file.

The core operations of your business logic often form the acronym CRUD, which stands for create, read, update, and delete. Imagine you’re going to create an item for a to do list over an HTTP endpoint. The actual operation will happen across three files: the HTTP parsing and validation is one. The file or database storage logic is two. The business logic for any sort of lookup or calculation before you store it (for instance, what time it was created) is part of your business logic, and is your third file.

For sample projects, this might seem like overkill, and it is. For anything larger than a sample project, though, it isn’t. By splitting up your projects in this way, you will likely discover that it’s easier to continue adding features and changing things (which is the point). But importantly, it shows potential employers that you understand and can apply this principle.

Hopefully, if you’re not used to factoring code, this might give you an idea of what other developers look for in your code.

Many consider Martin Fowler’s Refactoring to be the definitive book on this subject. It’s written as a series of recipes for how to perform each type of refactor.

Here are some links for further reading:

• https://dzone.com/articles/5-refactoring-principles-by-example
• https://myadventuresincoding.wordpress.com/2010/07/03/refactoring-principles/

My tip for new Scrum Masters

When I became Scrum Master, I initially felt pretty helpless. I had been trained, but the training told me to nudge people but not manage them. Guide and mentor the team — but let them be the drivers. I originally found these concepts difficult to grasp. I needed to figure out how to be effective.

What the training did not make clear to me is that when acting as Scrum Master, you are not focused on the topic being discussed. Instead, you are focused on how productive the discussion is. Is it in line with the goals of the meeting? Is it taking more time than can be afforded? One of ways a Scrum Master can help the team without interfering in its autonomy is with time discipline. I am still surprised how much the members of my team appreciate having someone who keeps the discussion on track and time-boxes discussions. For new Scrum Masters, I think this is a great way to be a value to your team.

Start by scheduling every meeting the team needs for the next sprint. This way you have the longest lead time to learn about vacations and odd schedule conflicts, and it gives you the best chance to have your favorite rooms.

A couple of days before each meeting, write a time-based agenda. Pay special attention to how long something really takes. For example, assume that you are going to break down Product Backlog Items (PBIs) and you have a one- hour meeting. Subtract ten minutes for late comers, setup, questions, and other beginning meeting noise and then decide how much time an item needs. If the team wants 10 minutes, then the Product Owner (PO) can bring in five items. I usually use 10 minutes to break down an item and give the PO the option to take another 5-10 minutes at the end.

In order to keep meetings moving along, you may need to get the discussion back to the main topic. Interrupting a person mid-sentence to keep a meeting on track is tough when you start as Scrum Master. It’s easier if you make a card, such as “Time” to hold up. Explain that you will do this up front so that everyone understands, and let the speaking team member wind down or summarize. In my experience people appreciate someone doing this, because you are respecting their time.

If you’re uncertain about the importance of the topic being discussed, when time is called, you can let whoever the meeting is for decide whether they need more discussion or just vote – thumbs up for yes and thumbs down for no.

I find it helpful to bring a stopwatch to meetings. A stopwatch is a dedicated device, so it works better than a cellphone, where you might need to mess with the screen turning off. It’s easy to read and operate.

It takes a lot of little things to increase the team’s velocity. Keeping track of time is a good place to start. It ensures all the meetings happen and that they are productive. But more importantly, people will be happier to go to meetings that are valuable and where issues are resolved.

Sample ceremony agendas (assumed attendance: five team members, Scrum Master, and Product Owner).

Standup (15 minutes)

• Make sure all P1 bugs are being addressed (1-3 minutes)
• Product quality status (1-3 minutes)
  • Note any failures in acceptance tests
  • Note current bug count
  • State any issues with current release
• Team member updates (1-2 minutes each)

PBI break down grooming (1 hour)

• 10 minutes — Noise
• Five PBIs for 10 minutes each
  • If a PBI runs over, PO has option to continue or move on

PBI bulk estimation (1 hour)

• 10 minutes — Noise
• 20 minutes — Team reads easy PBI out loud
  • Assuming that we have 20 PBIs to groom
• 15 minutes — Sort PBIs by complexity
  • Anyone who has a question marks the PBI with a sticker
• 10 minutes — Discuss any PBIs with stickers
  • POs go first
• 5 minutes — Bucket PBIs

Retrospective (1 hour)

• 10 minutes — Noise
• 15 minutes — Go around the room asking what went well and what went badly
• 10 minutes — Deeper discussion in impediments
• 10 minutes — Prioritize impediments to work on
• 10 minutes — Go over the team rules and ceremonies and make sure they make sense

Planning meeting (2 hour)

• 10 minutes — Noise
• 10 minutes — Discuss bugs for next sprint
• 15 minutes — PO goes over two sprints worth of backlog items explaining at a high level what they want next
• 15 minutes — Discuss order of items, missing items, impediments that should be added to top of list
• 10 minutes — Break
• 5 minutes each to discuss PBI
• Any PBIs that needed more discussion get the rest of the time

Fun with HTML escape codes

As I learn how to be a blogger (including the abandoning of Windows Live Writer), I keep finding lots of interesting new things. For instance, in my last post, I needed to escape the square bracket “[“. In my research, I found of list of HTML escape codes, including the one that I needed: http://www.degraeve.com/reference/specialcharacters.php

WordPress understands PowerShell

While constructing my last post, I wanted to include a PowerShell function. I attempted to use Windows Live Writer because I thought it would be easier to include code. Windows Live Writer had three source code formatting modules:

1. Insert Code (http://plugins.live.com/writer/detail/insert-code-for-windows-live-writer)

 

   1:  function Test-CodeFormatter

   2:  {

   3:      [CmdletBinding()] param()

   4:      

   5:      1..10 | foreach-object { "{0} {1}" -f "Hello", "World" }

   6:  }

1. Code Snippet (http://plugins.live.com/writer/detail/code-snippet-plugin-for-windows-live-writer)

   1: function Test-CodeFormatter

   2: {

   3:     [CmdletBinding()] param()

   4:     

   5:     1..10 | foreach-object { "{0} {1}" -f "Hello", "World" }

   6: }

1. Source Code Formatter (http://plugins.live.com/writer/detail/source-code-formatter)

  1: function Test-CodeFormatter

  2: {

  3:     [CmdletBinding()] param()

  4:     

  5:     1..10 | foreach-object { "{0} {1}" -f "Hello", "World" }

  6: }
All three of them looked pretty terrible in WordPress. After a little more Bing searching, I discovered: http://vkreynin.wordpress.com/2009/02/24/syntax-highlighting-in-wordpress-using-windows-live-writer/. This allowed me to paste my code in directly as html:
<pre>
function Test-CodeFormatter
{
    [CmdletBinding()] param()
    1..10 | foreach-object { "{0} {1}" -f "Hello", "World" }
}
[/sourcecode]</pre>

And it finally looked pretty. 
function Test-CodeFormatter
{
    [CmdletBinding()] param()   
    1..10 | foreach-object { "{0} {1}" -f "Hello", "World" }
}


									

Loading a .Net 4.0 Snap-in in PowerShell V2

I recently started developing a PowerShell snap-in, and without putting much thought into it, I created a .Net 4.0 project. After getting the initial code ready, I attempted to load the snap-in and got the following error:

This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

After a bit of searching, I found that this was not a PowerShell issue, but a .Net one, and the solution was to add to the PowerShell.exe.config file. The following was needed:

<?xml version="1.0"?>
<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0.30319"/>
        <supportedRuntime version="v2.0.50727"/>
    </startup>
</configuration>

(http://tfl09.blogspot.com/2010/08/using-newer-versions-of-net-with.html)

For PowerShell to work using remoting, the same solution must also be applied to wsmprovhost.exe (http://tfl09.blogspot.com/2010/08/using-later-versions-of-net-framework.html). 

In ultra-lazy fashion, I spent half an hour writing a function to place one of these configuration files for me, which is probably 10 times as long as it would take for me to do it all the times I will need to. However, writing scripts is fun.

function Write-DotNet4Config
{
<#
    .SYNOPSIS
    Function to write .Net 4 configuration files for me so I don't have to remember
    
    .EXAMPLE
    Write-DotNet4Config "$env:SystemRoot\system32\WindowsPowerShell\v1.0\powershell.exe"
    
    Writes a configuration for the given executable if none currently exists.
#>
    [CmdletBinding()]
    param($executable, [switch]$whatif)

    if (-not (test-path $executable)) 
    { 
        Write-Error "Cannot find executable $executable"
        if (-not $whatif.isPresent) { return }
    }
    
    if(test-path "$executable.config") 
    { 
        Write-Error "Path already exists"; 
        if (-not $whatif.isPresent) { return }
    }
    
    $versions = @("v4.0.30319", "v2.0.50727" )
    
    $config = @"
<?xml version="1.0"?>
<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        $($versions | %{'<supportedRuntime version="{0}"/>' -f $_})
    </startup>
</configuration> 
"@
    Write-Verbose "XML: $config"    
    Write-Verbose "Output file: $executable.config"

    if($whatif.isPresent)
    {
        Write-Host "What if: Writes to file $executable.config"
        Write-Host "What if: Writes xml: $config"
    }
    else
    {
        ([xml]$config).Save("$executable.config")
    }
}

									

Who am I? White, James White

Who
My name is James White, professional programmer. I rank among those programming geeks whose love affair started at a very young age–a maze game in BASICA. My background is in philosophy and psychology, although I did a bit of computer science study. Upon my discovery that one of these topics was more fun and paid well I became a professional programmer. Currently I work for Microsoft on Lync Server. My day-to-day work is focused on C# and PowerShell. To keep things spicy, I occasionally perform web programming, SQL, and C++, with a goodly portion of my time spent on MakeFiles and unit tests.

What
As someone who loves to read, I have many thoughts about many subjects. Lately those subjects are mostly programming theory, project management, and what thinkgeek toys are most fun to play with during compilation. Language theory and how languages change the way you code is a favorite subject of mine right now. I plan many posts on the uses and abuses of different languages.