Sitecore Developer Shortages: What we can learn from baseball and hockey…..

23. July 2015 20:54 by Mark Servais in Sitecore  //  Tags:   //   Comments (1)

Just an idea….some frontal lobe thought as I type actually.... 

So you have Sitecore, and you can’t find enough good Sitecore people to do the potential work coming in.  Unfortunately, your problem isn’t unique. In fact your problem really isn’t truly a Sitecore problem. The problem stems from not enough technology workers in general to fill all the demand.

The shortage in general STEM talent. Last year according to US News, computer science majors who graduated with a four year degree accounted for an approximate pool of 40,000 candidates. There were roughly four million jobs vacancies to fill with those 40,000 folks. Those who are graduating with STEM skills are commanding higher salaries because of the shortage.

Not my numbers, but for the sake of this article, I’ll use them cause I'm looking this stuff up as I'm typing this out.

At the July 9th meeting for the Milwaukee Sitecore User Group, John West talked to us about his background and his journey up to his current position at Sitecore. I don’t remember if it came up in a conversation I was having with John or someone else, but the comment (paraphrased based on memory) came out:

“Talent moving from one partner to another really doesn’t improve the community or Sitecore”

This is true. I made a change within the last year, it’s been a good move for my and hopefully for my company – but it’s done nothing for Sitecore directly.

We hire people from other companies all the time, other companies hire people away from us. The companies will have positive or negative results for this – but again it does nothing for Sitecore.

So, we are we continuing to solve an issue by doing the same things over and over again?

We either pilfer folks from other companies (which will continue) and we’ll try to race to hire those students from universities and waste tons of money trying to recruit and retain these individuals. We do things like nap pods, provide laundry services, free catered lunch, and other incentives. While these perks can be nice – most students want to help create intriguing systems.

So – look at baseball and hockey. These leagues have what are called farm systems. If you are unfamiliar with the concept -> https://en.wikipedia.org/wiki/Farm_team. This allows for the growth of your own talent.

We’ve been so reliant on universities to produce talent, we’ve neglected a whole potential process that may ease the issue.

To be really honest, I have nothing against universities and recent graduates. I think Software Engineering fundamentals need to be taught and practices followed in order to create consistent, reproducible success in delivering solutions.

Most companies don’t apply consistent, fundamental software practices. In fact when I started out – I just needed to know the language semantics for the systems I was working on. Certain topologies and methodologies used today didn’t even have a name.

So with a development farm system for your company, why could you not take anyone whom would be a good cultural fit for your organization (btw…a heartbeat does not constitute a cultural fit) who has aptitude to learn beyond semantics of a system’s language.

Don’t mistake a farm system just to be a series of college interns that do unrelated crap work. Think of a farm system for your company to be a proving ground for anyone that can meet the criteria whom you want to culturally hire. Young, old, enabled, disabled, tall, short, funny, serious, etc. (you get the picture) Train them semantically if you need to, but give them simple technical assignments. The basis of the farm system is real experience, not to get your remedial tasks complete. In baseball – this is player development.

“Coder development” is just the beginning of the development of career capital. Career capital is what makes us marketable to those who want more than a heartbeat.

So I’m thinking at this point you are skeptical and likely have two burning questions:

1.  WTF is this going to cost?

Yeah, don’t think you can get away with this at bargain basement prices. Training people whom are green at any STEM discipline is not easy by any means and requires investment. However following an approach of being able to profit from your farm system (again thinking of minor league baseball and hockey playing in smaller towns, smaller arenas, but still charging admission and filling seats) and managing costs (lower salaries, structured part time employment, etc.).

2.  How is success measured?

Like any other metric, it has a baseline and desired achievement level. So let’s say our metric is successful “graduates” of the farm program. So people in versus people completing the requirements for full-time “major league” positions. You can start looking at investment costs per graduate and how that applies to performance after graduation and compare that with those who don’t graduate and the costs lost in the investment. Obviously high graduation rates/low failure rates along with high efficiencies with folks after graduation is a winner here.

So I’ve discussed in a previous post what things you can do to become a Sitecore developer. So let’s talk about here about how you can safely try out a farm program.

First, start small. You don’t need a 12 person farm program to start out. Start out with no more than 3. Invest in those 3 people see where it goes and understand the success and failure characteristics to your metric.

Second, before bringing in anyone to the program – determine the minimal viable skill set (both technical of soft skill) for someone to join your program. Also determine the stepping stones in your program and determine what success means at each tier.

Third, you better have some good people that not only can work but can teach. Whether you take utilization away from your own staff of hire a specific technical trainer/mentor – the focus is you need some really good people to make some really great people. Include some Sitecore training in this as well if you are training for Sitecore.

Fourth, actively go out and find people to meet your criteria. Now, we talked about interns – but unless your criteria is specific it doesn’t need to be a series of interns. This is where you may need to break free of the typical thought of hierarchy in hiring and look for specific people in not so likely places.

I guess the final ingredient is some patience. Rome wasn’t created in a day, and creating Sitecore developers isn’t going to happen in a day as well.


Some frontal lobe thought to a common problem.

And remember – Just an idea as I'm thinking and typing… :)

Integrated Dynamic Placeholders: Closed Source

23. July 2015 18:40 by Mark Servais in Sitecore  //  Tags:   //   Comments (0)

As some in the Sitecore community know, Jamie Stump and I put together a module for Sitecore, Integrated Dynamic Placeholders, during the last Sitecore Hackathon. In 24 hours, we developed the ability in Sitecore to use a single placeholder setting in Sitecore to instances of a particularly named placeholder that is intended to be on your page in multiple instances. Like any 24 software development cycle, we rushed our design and development, hurried our documentation, and minimized our testing approach in order to meet the deadline.

 

Of course like all developers, we thought we tested enough. In early April later I had a former colleague reach out to me via LinkedIn to show me an issue he was having with nested placeholders not propagating. He provided me with some concrete examples of the failure and the condition to recreate. Unfortunately, Jamie and I were a bit occupied with work and family life tasks. Fortunately for us, my former colleague understood and was patient until we could free up.

 

Later that month I got a tweet about the same problem – however this was a member of the Sitecore community and not a former colleague. The issue here sounded the same, but again Jamie and I were underwater and had little to no time. There was more push to get this fixed as this person needed it for a big project they had been stuck on, and by the sounds of it needed it by the following start of the week. Jamie miraculously with his schedule, found some time to correct the issue the following week. It didn’t take him long to correct, the module just isn’t that big, but he finally got some time on the last day of the month to get it out the door.

 

Fast forward to June, and people have begun to use the corrected version of the module. Another Sitecore community member reached out, about release notes from the fix and code availability on GitHub as they had to abandon their use of the module during that initial bug duration. Honestly after the fix, Jamie and I never reopened the conversation about posting source. Early this month, we finally got together to quickly discuss the future of the source for the module. We decided not to share the source code, let me explain why we quickly came to this decision in a world that almost entirely demands that developers do so.

 

1.       Simplicity of the module doesn’t warrant it. Actually it is so simple I would hope Sitecore grabs it and just implements it in a future release. It took longer for us to talk about approach and potential execution than it took to actually code the thing. We wanted to make it seem Sitecore already had it in place when installed. Typically I wouldn’t care about sharing a small amount of source code except for reason #2.

2.       Managing the demands for pull request changes with limited time. I think in this case if the codebase was larger this might be time well spent, however because the code base was so small, it came down to the scale of efficiency for us to manage this module in our own time, versus managing our time around submissions.

3.       Time is limited. I think it is safe to assume everyone is busy – Jamie and I aren’t an exception to that state of being. In fact I don’t think I’ve been busier in all aspects of my life than the past year. One thing I’ve had to do with my interactions (both my technical life and non-technical life) is literally drop things that just don’t have substance for the immediate time. I know while I would want to dedicate time to manage requests, much like the commitment I have in other aspects, the reality is I don’t gain much managing change requests with tight turnarounds as I do planning releases and allocating the appropriate time to accomplish those goals. If this wasn’t a pet project and more of an official offering from a company that we were running – that of course would be much different. However, it isn’t and the act of collecting feedback and determining if fixes or enhancements are needed for a future release works best for us and ultimately the majority of the community.

4.       No matter how many contributors to the source, we eventually would have to manage it. For me, again it is easier to manage ideas and suggestions, than to manage source submissions and quality checks around them.

 

Not a popular decision that we made, but we think it works best for us in this case. So what do we lose by doing this, some really good stuff.

 

1.       That bug those two guys had found, had this been open source, might have been caught quicker and a fix proposed before we even had the chance to review it ourselves. In fact this could have been corrected in early April versus late April when the second report came in.

2.       Could there be a better way to do the same thing? I’m sure there is and everyone would have an opinion. Open forum overall I believe is good, and if we had something under our care such as Synthesis or Sitecore.FakeDB I would argue that sharing the source would be critical to the success of the module.

3.       The potential to work with folks on something we normally wouldn’t get to work with. I love to collaborate with other Sitecore people. Mainly that is why I do the podcast – it gives me that brief forum to discuss topics with other people that normally might be frowned upon from past employers – especially those previous to my days working with Sitecore.

4.       Recognition of work done. Don’t get me wrong, I like a pat on the back as much as the next person – but it isn’t why I do what I do by any stretch of the imagination. This one doesn’t hold weight with me so much. I can live without it. There are some guys in the community (Mike Edwards/Glass, Adam Najmanowicz-Michael West-Mike Reynolds/Sitecore PowerShell, and so many more) that have this recognition and do what they do because they care, can support the effort they are putting in, and can capitalize on the efficiency gained by social coding. I don’t think they do it for the recognition either.

 

So again, at this time we have decided not to release the source code. I truly do hope this does make sense to everyone whom has shared concern about it.

(XCentium) Sitecore's GetActiveUser Result Isn't Always The Active One

23. July 2015 18:37 by Mark Servais in Sitecore, ForEmployers  //  Tags:   //   Comments (0)

Blog post I did for XCentium:

http://www.xcentium.com/blog/2015/07/08/sitecore-getactiveuser-result

Calendar

<<  June 2019  >>
MonTueWedThuFriSatSun
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

View posts in large calendar

Month List