De-Coder’s Ring

Software doesn’t have to be hard

Month: May 2016 (page 1 of 2)

Developers: get a haircut, and get a real job


There’s an interesting problem going on within the IT industry.   I’m sure it reaches beyond software engineers, but that’s where I’m going to focus.  Do you know any developer who’s out of work?    Any that can’t find work?  Any that AREN’T contacted by recruiters regularly?  I don’t.  We are all gainfully employed, and we continue to get bombarded by potential roles.

Ok, I’m going a little emotional up there.  Sure there are folks who are unemployed, and they may be good at what they do, but I would venture to say that the vast majority of good and likable developers are employed and compensated pretty darn well.

Hiring Managers

The problem that I want to talk about is the lack of developers in the US.  One of my recent ‘roles’ as a consultant has been to work with companies on how they hire and retain engineers.  It’s not about making the perfect job description or using the right buzzwords (Those help!), but it’s about finding the type of person you need and being willing to cross train or have some patience while they learn a new technology or programming language.  I once read a comparison to someone hiring a painter.  You don’t ask your painter how long they’ve been painting grey walls, or white ceilings, you ask them how long they’ve been painting and about the quality of their work.  In software development, sure, it would help if you have a Java program to maintain to find a Java developer.  If you’re having a hard time doing that, reach out to someone with Python or C# history.   Good developers know how things work beyond the code their writing. It then makes it almost trivial to learn the syntax of a new language.

That’s not universally true, though. For instance, I wouldn’t hire a Linux administrator/perl programmer to work on big data problems using some cool Python or Java frameworks.  I would hire someone who’s written Scala using Spark, to do some work in Java/Spring Batch.  The big rocks are the same.  It’s the color off the moss growing on top that’s a little different.


Developers, if you ARE challenged with finding a job, here are some thoughts.

Stop focusing on buzz words

Quit talking exclusively about the technology you used.  You could come across as narrow focused, and basically a trained monkey.   Let’s compare it to carpentry.  Anyone can use a jig saw, but, not everyone has a product to sell that people will buy.  Don’t just tell me about the tool you used, tell me wha the problem you solved?  What was your role on the team

Your title doesn’t matter

Much like the idea of the tools you used, what was your role on the team?  Sure, your role could be Senior Master Principal Developer, but if all you did was follow a spec written by your technical lead, then it doesn’t matter.  Tell the hiring manager what YOU did.  Not what the team did either, what was YOUR role in success or failure.

Quit lying and know your stuff

This should seem obvious, but I can’t tell you how many interviews I’ve performed in which the applicant couldn’t talk about the above concepts. Sure, they said they used Java, but couldn’t tell me how a Servlet worked.  Once, I had a web application developer who couldn’t explain how an HTTP request worked.  Don’t get me wrong here, I’m not looking for a detailed explanation of network packets or the HTTP 1.0 protocol (although that would have been bonus points, since we were building a network forensics tool).  I just wanted to hear something like request-response, or client server… anything!


This article started to talk about the shortage of talented developers in this day and age.  This is going to continue to get worse, as the appreciation and demand for quality engineers rises.  In the future, I’m going to write down some ideas on how to fix it.

In the end, this is some pointers for hiring managers as well as developers on how to open up their options a little bit.  The key point, be flexible in who you may hire as long as they are close!

Cross posted at:

Volunteer for Personal Gain

** Everyone should volunteer their time, and donate money to their church or non-profit/charity.  If you don’t, reevaluate your values.  If you’re reading this, odds are you have more than you need.   **

The most precious commodity we have is our time.  Once it’s gone, you can’t get it back.  You can not buy more of it nor is there a massive trove of undiscovered time in the sands of Canada or under the Gulf of Mexico.  It is imperative for us to use all the time we have in a wise manner.  Sometimes that’s work, sometimes that’s time with family and other times that’s watching TV (we all need a little down time.. just not 45 hours a week seeing who got kicked off the island).

An area of my time that I put to good work is volunteering.  I spend hours a week at church or at my kids school.  By using skills that I’ve learned, I can share knowledge and my passions with other people.  On top of using knowledge I already know, this is an awesome time to learn something new.  Extend your personal boundaries and get our of your comfort zone.

Think about your volunteer time strategically.  Choose a leadership position on a committee that may or may not be in your field.  I ran the ‘HR’ department of my church for 2 years.  I’m not a HR person by any stretch, but I do care about other people, the church and making sure the staff was treated respectfully, fairly and by the book.  This type of an opportunity will hugely benefit ME going forward too.  It also benefitted the church by having a dedicated and concerned volunteer in a position that isn’t anyone’s favorite role.  It has to be done, but it’s not easy.

This year, it’s about being on the finance committee.  What the heck do I know about institutional finances?  Nothing!  BUT, I do know a lot about personal finances, and I have some very strong and clear beliefs on how to responsibly use money.  This allows me to step outside of my comfort zone, but again, learn something that can help me when I need to worry about finances of a company I start or a run a division of which I have financial responsibility for.

Now, if you’re reading this and thinking “He’s just humble-bragging”, you’re doing it wrong.  You’re missing the point.  Do good work for other folks, if you can, learn something while you’re doing it.  Don’t just put in the time. Anyone can just put in time and mark the checkbox.  “Yep, volunteered this week”.

Cross posted at:

Product Managers: Your engineers can’t stand you

Why are you here, product managers

I was digging through some of my old notes.   Nothing specific to the operations of the company, but personal notes.  Previously, I was the first person hired in a startup after the founders decided they wanted to make a ‘real go at this’.  In those first months, there were a few engineers, product and sales folks hired.

An area of interest I’ve had is the collaboration between engineers in a product development function and the folks in a product management function.   This relationship is collaborative and contentious at the same time.  I find that funny, since in a company that’s creating a new product, the goal of everyone is that of creating the best product for their customers.  Think about a technology startup.  People are doing one of two things: selling or coding.  The issue with that statement is, who’s telling the coders what to code, and telling the sales folks what to sell?

Product What?!

A startup technology company needs product managers.  Their title may be VP Product Management, it may be CEO, it may be CTO, it may be Customer.  Someone is going to play the role of PRODUCT MANAGER.

Engineers need a target to code to.  While it would be fantastic to write code for the sake of writing code, someone has to pay for it.  It we don’t get paid, we don’t eat. If we don’t eat, well,….  we can’t code.

Product Managers

There are a few items that need to stand out as your responsibility.   You need to have the vision. Constantly be in touch with your potential customers as well as the executive committee of your company.  My job is to write software, create development practices and to define how applications will work with other software.  You need to make sure to have a solid list of components for our appliance or platform. Work with our vendors to make sure they are shipping the appropriate hardware.  Guarantee them our sales volume so they have the stock of components on hand before we really need it.

Define the story.  Paint the picture of the future and the purpose of the product.  From your product engineers stand point, this is the way you can influence them the most.  Cast the vision.  Let them see what you and your customers see.  Why is it important that we’re working our tails off for this product?  Why does it REALLY matter?  Technology can solve real world problems.  It can save lives, it can save identities, it can protect secrets.  Tell your engineering team the value they’re adding.   Influence them by telling them how important it is what they’re doing.

Final Point

The point of this article is to help product managers work with engineers.  I have an insanely strong respect for product folks and absolutely realize their importance and value.  I’m not normal.  There are a lot of engineers, in startups and established companies that don’t understand.   They need to be educated.  The easiest way to educate them is to provide them value.   Product folks, the best thing you can do is to show them why it’s important they’re building what they’re building.

Cross posted at:

Right Tool, Right Job

Today’s landscape for software engineers is amazing.  There are open source tools to do everything!  There are commercial tools to do everything!  With high level programming languages, we can write code to do everything!   Where the heck do you start?

Building a new platform or capability can seem like a daunting task.  I’ve worked with many companies and teams that undertake new development processes with a bit of discomfort.  They know that the project will ‘take forever’ to build, will probably be over budget and won’t be easy to follow through to completion.  Even the best teams, hindered by the wrong technology choices, will struggle to complete their tasks on time and will not perform at their peak.

One really interesting example of when I ran into this problem was a few years ago.   A team was using Sharepoint to build a search tool.  They had duplicate systems (from acquisitions, etc) that had the same ‘type’ of data in them.  When a new ‘thing’ was created, they had to check all the other systems to see if that ‘thing’ already existed.  The idea was to use the full text search capability of Sharepoint to ingest the data, and serve it via a web UI.   Sharepoint checked all the boxes.  It could ingest data, it could index the data and provide a UI.   (If you were on that project, and you’re reading this, no harm meant here.  You were using the tools you had available).

What went wrong?

Sharepoint sucks!  Well at least at that point in time, that version of Sharepoint could NOT handle the volume of data being thrown at it.  Sure, it could index and search the data, but it took 24+ hours to ingest the millions of rows.  Wow!  So much for getting views of fresh data within 5 minutes (arbitrary business requirement).   Something had to give.

What was right?

After doing a little bit of research off the side of my desk, ( I wasn’t directly associated with the task, just knew what was going on), I found Apache solr.  Looking back through the solr archives, it was Apache Solr 1.4 or so that I discovered.  It seemed magical.  Configure data sources, use JDBC, execute query, ingest data, etc.   Man, did it scream!   The initial/daily data load took 5 minutes. The delta loads were near instant.  This was the right tool for the job!

As an engineer, that’s just one of the many examples of finding the right tool for the job.  It takes curiosity and a quick sense of analysis (and some intuition) when figuring out how to tackle a problem.  Let your folks experiment.  Don’t use the hammer you have, because it’s the hammer you’ve always used.  Don’t use a hammer when a rock will do.



Cross posted at:

Older posts

© 2017 De-Coder’s Ring

Theme by Anders NorenUp ↑