Tag: hiring

The Fallacy of “Years of Experience” in Software Development

In the ever-evolving landscape of software development, the metric of “years of experience” has long been considered a gold standard for assessing a developer’s expertise. However, as the industry matures and the complexity of technology deepens, it’s becoming increasingly clear that this measure is not only outdated but often misleading. Let’s dive into why “years of experience” should no longer be the primary gauge of a developer’s prowess and explore what truly reflects a developer’s skill and impact.

The Irrelevance of “Years of Experience”

  1. Experience Doesn’t Equate to Expertise: Merely clocking in years at a job does not guarantee a deep understanding or mastery of software development. A developer with ten years of repetitive, unchallenging tasks may know far less than a developer with three years of intense, varied projects. Quality and diversity of experience eclipse the sheer passage of time.
  2. Rapidly Changing Technologies: The tech world is in a constant state of flux. Programming languages, frameworks, and best practices evolve at a breakneck pace. A developer who hasn’t kept up with these changes may find their once-relevant skills becoming obsolete. It’s not about how long you’ve been coding but how well you’ve adapted to and adopted new technologies.
  3. Innovation and Problem-Solving Over Time Served: Software development is fundamentally about solving problems and innovating. A developer who consistently finds creative, effective solutions and can bring them to fruition is far more valuable than one who simply logs hours. Innovation is not a function of time; it’s a function of mindset and approach.

Better Measures of a Developer’s Skill

  1. Successful Solutions Deployed: A more meaningful measure of a developer’s capability is the number and impact of successful solutions they’ve deployed. This includes applications, systems, and features that solve real-world problems, meet user needs, and provide business value. A track record of successful deployments speaks volumes about a developer’s practical skills and effectiveness.
  2. Longevity and Iteration of Solutions: For developers with 5+ years in the field, an excellent metric is the longevity and continuous improvement of their solutions. How many of their deployed solutions are still in production and actively used? More importantly, are these solutions being iterated on and enhanced, either by the original developer or by others? This indicates not only the robustness and relevance of their work but also their ability to build maintainable, scalable systems.
  3. Breadth and Depth of Projects: Evaluating the variety and complexity of projects a developer has tackled provides insights into their adaptability and breadth of knowledge. Developers who have worked across different domains, tackled diverse challenges, and delivered under varying constraints are likely to have a richer, more versatile skill set.
  4. Community and Contribution: Active participation in the developer community through open-source contributions, technical blogging, mentoring, and speaking engagements can also be a strong indicator of a developer’s passion and expertise. These activities demonstrate a commitment to continuous learning and sharing knowledge, which are crucial traits for staying relevant in the tech industry.

The Path Forward

As we rethink how we assess software developers, it’s crucial for hiring managers and team leads to shift their focus from years of experience to more meaningful metrics. By valuing successful solutions, the longevity and iteration of these solutions, and the breadth and depth of project experience, we can better identify truly skilled and impactful developers.

In practice, this means asking different questions during interviews, emphasizing problem-solving and project-based assessments over resumes and tenures. It’s about fostering an environment where continuous learning, adaptability, and innovation are prioritized and rewarded.

In conclusion, while “years of experience” has been a convenient shorthand, it’s time we move beyond it. Let’s embrace a more nuanced, accurate understanding of what makes a developer truly great. Because at the end of the day, it’s not about how long you’ve been in the game; it’s about how well you implement and play it.

The Reality of “Code Challenge” Culture Outcomes Among Large & Small Organizations

Key definitions for this article:

“Code Challenge” Culture: This culture is more of a “do as we say, we’ll grow you as we see fit, and you may then continue with us if you perform accordingly” type of environment. It starts with a more defined, strict adherence to an academic achievement type environment that enforces one do things a certain way and follow a certain path, and to ensure you too will do those things a code challenge is used to gate keep a particular job role. There are obviously good and bad results to this culture, and this article is going to get deep into those cultures.

Wholistic Culture: This culture is more open to getting a larger picture idea of a candidate in the interview pipeline. With more of an intent around having the individual develop the organization and for the individual to learn. The possibility of bringing knowledge that can help one improve the organization is readily accepted as is an individual that might not pass a rigorous academic code challenge to shift arrays, or move bits, or trickle values around a binary tree! There are however, good and bad outcomes to this type of culture.

Caveats: In both cultures there are numerous additional criteria that changes them. In this article I’ll write about them in a general sense, and then when detailing something specific, I’ll state that caveat with a call out.

The Big Organizations & Smaller Niche Organizations

I’m going to use three big companies and three small companies here that have varying degrees of “Code Challenge” Culture. In that, I’ll dive deeper into the problems that arise from a strict “Code Challenge” Culture vs. a Wholistic Culture.

Continue reading “The Reality of “Code Challenge” Culture Outcomes Among Large & Small Organizations” →

An Engineering Manager Challenge

This post came to mind while reading this post on LinkedIn, which is a share of this post by Kelvin Mai, and the follow up post Ted Neward made here. Read up on those for more insights into this topic.

Before diving into the details, it’s important to note that the criteria outlined here leave several questions unanswered, which could significantly impact the final decision. Factors like the specific nature of the projects, team dynamics, and long-term strategic goals are crucial and could sway the decision in different directions. That said, let’s break down the options.

Bringing on Two Junior Developers

Pros:

  1. Boosted Bandwidth: Two fresh faces mean more hands on deck to share the workload, increasing overall throughput.
  2. New Blood, New Ideas: Junior hires come with fresh perspectives and a ton of enthusiasm that can rejuvenate the team.
  3. Long-term Investment: Junior devs are like seedlings; with the right nurturing, they grow into valuable assets, contributing more as they develop.
  4. Flexibility: Juniors can be shaped to fit the team’s needs and culture, making them adaptable assets.

Cons:

  1. Boosted Bandwidth: Emphasis here though is on “throughput” above in the pros and not on committable, usable, and well written code you want and can use in the project. Increased throughput can be a negative, and IYKYK and can think of this as “induced demand” but for code.
  2. Training Time Sink: Juniors need a lot of guidance, which can be a major time drain for the senior members.
  3. Ramp-up Period: They won’t hit the ground running. Expect a learning curve before they start delivering at full capacity.
  4. Management Load: More people means more management. Even if they’re juniors, it adds to the admin overhead.

Hiring One Senior Developer

Pros:

  1. Expertise on Tap: A senior dev brings a treasure trove of knowledge and experience, perfect for tackling complex challenges and making strategic moves.
  2. Mentorship: They can mentor junior team members, leveling up the entire team’s skill set.
  3. Quick Impact: Seniors can dive in and start contributing much faster than juniors, thanks to their experience.

Cons:

  1. Higher Price Tag: Senior talent doesn’t come cheap. They’ll command a higher salary, impacting the budget more significantly.
  2. Cultural Fit Risks: There’s always the gamble that a senior hire might not mesh well with the existing team dynamics.
  3. Single Point of Failure: Relying on one senior dev for critical tasks can create dependencies, potentially leading to bottlenecks.

The “Do Nothing” Route

Pros:

  1. Save the Budget: Not hiring anyone saves money, which could be redirected elsewhere.
  2. Focus on Current Team: No new hires mean you can double down on developing and optimizing the current team.

Cons:

  1. Opportunity Cost: Leaving budget on the table means missing out on potential gains in capacity and productivity.
  2. Burnout Risk: Your current team might end up overworked, risking burnout and decreased morale.
  3. Stagnation: Without fresh talent, innovation can stagnate, and the team might struggle to keep up with growing demands.

The Decision

Let’s get real: not hiring anyone is likely the worst choice here. I know some would disagree in some situations, but if you’ve got budget allocated for new talent, use it! Even if the ROI isn’t immediate, it’s about positioning the team for long-term success. Hiring is an investment in the future—whether it’s two eager juniors ready to grow or a seasoned senior ready to lead and mentor. In this scenario, hiring one senior developer is the strategic move. You’ll get immediate expertise, mentorship for the juniors, and a stronger foundation for future growth. Let’s make that budget work for us and set the team up for success!

Addendum

This post attributed to leading me down the path to elaborate on staff and hiring details, including The Toxic Truth About Coding Challenges in Technical Interviews and then the elaboration on that post with The Reality of “Code Challenge” Culture Outcomes Among Large & Small Organizations.

Recruiters -> Software Developer Referrals, I Know Em’, Here’s How You Know Them

This is a public letter to all recruiters, human resources or other professionals that are in a *hiring department* that would like to garner referrals from me. I like to categorize my referrals into junior and senior software developers. This is not my interaction process with startups & early round companies, I know you and you know me, things work differently, so if you’re in a startup and looking for people this doesn’t apply to you. This is a letter to help guide how I can help all parties involved in the best way possible.

NOTE: I’m not a recruiter, not intending to be, nor do I work for any recruitment agencies or groups. This is something I do because I enjoy being involved with the tech scene of Portland and have great sympathy for people looking to join good teams. I fought years to find good teams and have enjoyed working with these teams. Matter of fact, I’d say a good team is orders of magnitude more enjoyable to work with than the not good teams. In other words, I try to make things not suck for everybody involved!  😉

For junior developer referrals, I have a few basic requirements and information that I’d like to know if there is a specific job in mind. If you’d just like to talk, I’ll also put you in touch with a junior developer based on this criteria.

  1. For the junior developer the positions should be of reasonable commutes, especially in the current software development market. This means that the commute, one way, should not be anymore than 10-15 minutes either by biking, walking or taking transit. If they want to drive, that’s their concern, but I don’t want to condemn anyone to ever being stuck with a forced auto-dependent commute.
  2. Is there opportunity that the junior dev will be working with other senior developers who will pair code, do code review and otherwise support the individual in a positive and enthusiastic way?
  3. Is the company active in the local community and supportive of new employees and existing employees being involved? Will the encourage and allow the junior developer to get involved and possibly attend workshops, courses, meetups and even conferences that may be during business hours (but likely most are not)?

For senior software developers this gets to be even more particular, especially in Seattle, Portland, San Francisco, New York or Vancouver BC. If I’m going to refer anybody the following items are a baseline.

  1. Does the job offer remote work or some remote work days? How does the team currently communicate with remote employees and what is the split of remote employees vs. in office employees?
  2. Not just is there opportunity to, but is there active pairing, continuous integration or delivery setup and being used?
  3. What is the current management paradigm around architecture decisions, user experience (UX) and other items that are often peripheral to the software development that occurs?

If these questions can be answered in the affirmative then I have some referrals for you. Even if they aren’t, these questions and this information should become standard on any job description, in MANY ways more so than the technology list of skills that are all to common. This last part is something to note for people hiring, not just recruiters.

I’ve also talked more about this far in the past (in tech years). I’ve spent many solid years hiring, firing and generally building teams of people. The following has inadvertently become kind of a series about suggestions to fix the job posts, and where and what the baseline is for building a A-game Team. Much of these suggestions hold true still today.

I’m Not Looking, But These Job Posts Just Suck

BEWARE:  This is the beginning of a rant.  If you’re temperamental it might piss you off.  You’ve been warned, prepare to have a bit of rant with reality thrown on top for good measure.

I’m not looking for another gig.  I’m extremely happy with what I’m doing right now.  The Russell Team I’m working with absolutely rocks!  On our worst days we kick ass and on our best we kick ass, take names, and build lots of software with value for the company and users.  We produce software, with reasonable timelines, timelines that we have input into, with good business proponents, solid technology, quality code, and generally sound process.  All this with strong overtones of Scrum influence ala from the Agile Manifesto.  People on the team actually KNOW and have READ the Agile Manifesto – which is AWESOME!!!!  🙂

So now that I’ve got that declaration out of the way I want to write a very serious rant to managers who have never read the manifesto and claim they use an “Agile Process” or “agile” or whatever.  This is a statement and rant to those companies that go recruiting for top tier people (and rarely get them) with horribly written job descriptions and practices.  So let’s get started, and the developers out there, let me know if you are annoyed by these practices too!  I’d love to get an ear full form anyone from any side of this equation.

If you use an Agile influenced process (notice I said influenced, because really there is no such thing as an Agile Process – it’s an ideal, kind of like freedom and liberty) nobody should be reading or printing things like;

  • Agile = Agile Principles U Agile Best Practice
    Agile = Agile Principles U Agile Best Practice

    “This project is being run using agile methodology.” < Really? Which one? That isn’t very descriptive. It’s kind of like me saying, “I like to eat food, the cooked kind, sometimes, cuz it’s good!”  Yeah, really! Dear oh dear. Translation: “I went to a management conference and somebody said that I HAVE to use agile methodologies or I’d be a failure.”

  • Yeah, It's In There Somewhere, The Piece That Will Bind the Meaning of this Description Request!!
    Yeah, It’s In There Somewhere, The Piece That Will Bind the Meaning of this Description Request!!

    “Good understanding of software design and concepts and patterns.” <  First things first, there are way to many ands in that sentence. Second, Which design, concept, and patterns?  Microsoft’s, Computer Science, or Agile Manifesto related concepts. This again is a very vague statement.  Kind of like stating, “We want someone to write software that can write software”. For real!  😮

  • “Experience using Visual Studio 2008 and the .NET Framework V4 with experience using Framework 3.5 with SQL Server.” WTF?!?!  Ok, you state you’re using the “agile process” but the first thing this does is prove you’ve probably broken the first manifesto point, people over tools. You’ve just declared tools, and in addition to that the tools are correlated incorrectly. Using SQL Server has ZERO to do with what .NET Framework you’re using. Using .NET 4 is almost identical to 3.5.  Declaring the version really isn’t necessary.  In addition, declaring a framework version with SQL Server would lead any decent developer to think that the project is already messed up since the tools description is correlating .NET 3.5 to SQL Server – which should make absolutely no difference.  Zero, Zilch, Nada!!!
  • “Familirarity with the basics of WPF, Silverlight, WCF, and Azure.” <- So every application in the universe is getting built?  This just adds to the confusion already generated by the oddball descriptions above. At this point a GOOD software developer would either stop reading and ignore the posting or be so curious as to why its screwed up they’d contact the recruiter or posting company. I know some developers that have literally contacted a company to ask, “what is being stated” in a job description.
  • “Awareness of Microsoft TSQL and database design principles.” <- Again, ok, but you already said SQL Server.  Maybe you mean some magical mystical unicorn generating SQL Server in that previous request and this is for just the SQL in the magical mystical unicorn SQL Service generating Unicorn TSQL Microsft TSQL Database Widget! Yeah, that’s it.
  • “Demonstrated ability to follow through with all tasks, promises, and committments.” <- Ok, I’ll admit, some places probably need to post this.  But when I see this, I’m putting my money on the idea the management probably sucks, and not a little bit but a whole lot. The other possibility is that the hiring staff have no idea how to communicate or infer if a person has basic abilities A company demanding the basic fealty of honesty and integrity in their employees in the job description something is SERIOUSLY wrong already.

  • Bad Communication Happening
    Bad Communication Happening

    “Ability to communicate and work effectively within priorities” <- Ok, with that previous demand of fealty and competence, this request right after is a HUGE read flag screaming that communication is most like NOT good in the environment the job is in.

  • Yeah, Do It, Do it RIGHT NOW!!!
    Yeah, Do It, Do it RIGHT NOW!!!

    “Ability to work under tight timelines in a fast-paced environment” <- Again, this completely throws out any concept of maintained velocity, a good agile understanding, or any hope that someone actually read or understands the Agile Manifesto and Principles. It also provides the hint that maybe, with a high likely hood, management is grasping at straws trying to keep things going in the right direction.

I wouldn’t be very likely to respond to this job entry if I was looking. Matter of fact I’d warn people (kind of like I’m doing with this blog entry). In my next entry I’ll provide some actual GOOD job descriptions and things that I would look for, if I were looking (which I’m not, as I’ve pointed out).

Frustrated... looks like it.
Frustrated… looks like it.

…and don’t get confused, I’m not being a prima donna or demanding blue M & Ms only. I’m merely asking that people get their shit together and treat their prospective employees with some honesty and integrity also. Hiring practices leave a LOT to be desired in the world of the tech industry. They’re horribly inefficient from both perspectives.  It is hard to find people and hard to find good gigs that one can truly be happy with. I honestly feel though that getting this straightened out, if it is to be straightened out, is a better understanding on the hiring side and on maintaining a healthy, functional, and productive work environment.

Stay tuned, and I’ll have the “much closer to ideal” job posting ideas up here in the near future.  For now, I’m done ranting about this.