Junior Devs, Training, and Management

Just a random observation — I’m saddened when I encounter a management mentality that makes no effort to educate their junior devs so they can eventually become senior devs.

If you don’t have a decent knowledge of the programming language, framework and tools you’re working with, the way you “code” is like someone with a 3rd grade vocabulary trying to express a complex thought.

How do you educate junior devs?

  • Code reviews by senior devs.
  • Training sessions given by senior devs.
  • Having time allocated to learn.
  • Instilling an interest in learning!

Realistically though, nothing can overcome the “it’s a job, not a passion” attitude in the junior dev him/herself.  If the junior dev has a passion for software development, they’ll most likely educate themselves on their own time, not just the company’s time.

But then, when they have learned, they’ll move on because the work environment suddenly becomes limited.  An interesting dilemma for management, especially as they can now ask for a considerably higher salary than the company wants to pay for, which is why they hired junior devs to begin with.

The Joel Test: work vs. home

Joel Spolsky, 18 years ago, wrote “The Joel Test: 12 Steps to Better Code“.  Granted, it’s 18 years ago, but I thought it would be amusing to score my home work environment with my work work environment:

One point for each yes:


Do you use source control?  1/2 (yes, but not properly)
Can you make a build in one step? 1
Do you make daily builds? 0 – no, manually initiated
Do you have a bug database? 0 – not that I’ve ever seen
Do you fix bugs before writing new code? 0 – hahahaha
Do you have an up-to-date schedule? 0 – schedule, what’s that?
Do you have a spec? 0 – do you count screenshots in Excel as a spec?
Do programmers have quiet working conditions? 0 – unless you count needing to wear headphones
Do you use the best tools money can buy? 0 – VS2015, .NET 4.5, etc.
Do you have testers? 1
Do new candidates write code during their interview? 0 – I wasn’t.
Do you do hallway usability testing? 0

Score: 2.5


Do you use source control? 1
Can you make a build in one step? 1
Do you make daily builds? 0
Do you have a bug database? 1
Do you fix bugs before writing new code? 1/2 (I really try to practice this)
Do you have an up-to-date schedule? 0 – my clients are pretty loose about schedules…
Do you have a spec? 1 – …but they’re good about specs.
Do programmers have quiet working conditions? 1 (as in, total silence)
Do you use the best tools money can buy? 1
Do you have testers? 1 (assuming the client doing the testing counts)
Do new candidates write code during their interview? 0 – don’t interview people
Do you do hallway usability testing? 0 – unless the cats count.

Score: 7.5

It’s sad how my home environment scores considerably better than my work environment.  No wonder there’s a “no telecommuting policy”, right?


Office Politics and Sh*tty Code

office politics.jpg

Kent Sharkey on Code Project recently asked this question:

I’m just curious to know how everyone else here deals with poorly written code in pre-existing projects.

Here’s my answer:

A few of the common questions about the code:

  • Is it bug riddled?
  • Is it hard (or impossible) to add new functionality?
  • Does it run only on/with obsolete or soon to be obsoleted technologies?
  • Does it have performance problems, and are those performance problems intrinsic to the architecture (or lack thereof)?
  • Is there a complete lack of unit and integration testing?  Would the code simply benefit by developing a test suite?
  • Is deployment a PITA?
  • Is the project set up correctly?  Does it have development, test, stage, and production deployment environments?
  • Are the tools being used for development archaic?

Regarding office politics:

  • Is the original coder/team still around?
  • Is there an adversarial situation between the coders and the users?
  • Does management b*tch about the problem but refuse to allocate the funds to fix it?
  • Has management become jaded with in-house development and thinks outsourcing / third party COTS, or bringing in a consulting team (at 10x the cost of in-house development) will fix the problem?
  • Does management think patching the code rather than rewriting it will fix the problem?
  • Does management even trust its developers?
  • Do the developers trust their managers?
  • Do the customers (in house or otherwise) trust the coders?
  • Do the customers trust the company / managers?

So, before even touching sh*tty code in an environment rich in office politics, those questions need to be answered and the issues addressed:

  • Managers, developers and customers need to be brought on board with small wins.  This doesn’t necessarily mean fixes in the code.  It also, and much more importantly, means communication, particularly, feeling heard.  And that means not just listening to the complaints, but coming back with a prioritized plan to address those complaints.
  • Develop trust before developing code. That’s a cute slogan, but think about how you communicate a project plan, even a small one, and how you present measuring success, how you communicate progress and obstacles, so the coders, managers, and customers (in house or otherwise) all, and I mean all, feel confidence moving forward.
  • Everyone needs to see themselves as a stake holder. Particularly, that means management needs to be interested, involved, and engaged in the fixing process. No “disconnected” management, the typical “do this by then or else” style of management.  Customers need to be engaged too with testing fixes and providing feedback.
  • Fix the blame game so that people are oriented toward solutions.
  • Get 100% agreement (even if everyone starts at “this all sucks”) and move rapidly towards 100 % agreement on “this is how we make it great.”
  • Instead of daily stand ups of “what did I do, what am I working on, what are my obstacles”, focus instead on “how’s my enthusiasm level, how well am I working with others, how well are others working with me.”
  • Lastly, be honest, and if you think someone isn’t being honest, call them on it. If trust and honesty doesn’t rapidly become the new culture, then accept it and move on to another job where the climate is healthier.

Those are all things I’ve encountered and is the boilerplate list of questions and “moving forward” approach that I take.