How To Build A High Performing Programming Team

TeamLeadI regularly see programming teams that are terrible. The customers are unhappy. The manager is unhappy. The programmers are unhappy. The code is unhappy. Their system is broken, or maybe they’ve got no system at all. If this sounds like your team, I think I hear a better way calling your name.

Technical Lead(er)
In my experience, the fate of the team hinges on being able to find a rockstar developer to lead the charge. While this is the most important position to fill, it’s also the hardest to fill. My recommendation is to do whatever it takes to get an experienced programmer who knows how to lead. Up your budget. Expand your search parameters. Invest in training a programmer on your team who has leadership but lacks platform knowledge. If you’re a project manager, you may have to fill in as technical lead for a while.

Your lead developer needs to be addicted to learning about better programming and leadership. He has to quickly learn your environment from a technical perspective inside and out. Communication is important, and so is a strong desire to teach other programmers. This is the one who will define coding process, release process, and coding standards. He needs to know what good code looks like as well as bad code, and the same goes for good and bad processes. I know it’s a long list. You probably won’t find a perfect fit, but your success depends on getting a near match.

Loyal Followers
Once the technical lead is in place, the next step is to find programmers who will implement the plan laid out by the lead. I’ve had good success with having coders at various stages of their careers. Regardless of what stage they’re at, every programmer on the team should be interested in progressing their career and should be willing to put in some extra time to get there. Determination to become a great programmer will breed more of that same attitude if it’s something that you deliberately cultivate. So take the extra time to encourage your team members and provide a clear picture of how the future could look.

Because you may have had to go a little over budget on your lead, you might have to play some money ball here with the other developers. Again, you’re looking for a teachable attitude and a desire to become a better programmer. Maybe this means hiring someone who’s been out of the programming game for a couple years or who’s strength was programming in another language. Don’t be dangerous, but there will be some risk involved.

I’m also known for hiring non-programmers for my programmer on deck spots. These are typically software tester roles where down-time in testing is spent doing simple coding tasks. This helps out getting some of the low-level programming tasks done and gives the tester a chance to “try on” programming.

I’m constantly looking for people interested in starting to program. Even if I don’t have an open testing spot, there will probably be a spot opening up in the future. From my perspective, everyone should be a programmer. Is there a better occupation out there? I think not.

Making The Cut
In order for your team to be great, you’ll likely need to let some programmers go. If the quality of work is low, have a 1 on 1 conversation with the programmer. Do whatever you can to change the behavior. If the results don’t improve or there is no effort being put toward correcting the issue, it’s time to think about doing both the programmer and the team a favor. Great teams can’t have members who don’t want to be team contributors.

Employ A System
If you’re seeing a problem, there’s likely a procedure that you can put in place to fix the problem. Once a procedure has been put in place, the hardest part is sticking with it. Don’t implement more rules than you can keep track of or than can be enforced. If you do, you’ve become part of the problem.

Move Towards Success
Building a great programming team takes time and effort. If you have a clear picture of where you’re headed, you can start making incremental changes to start transforming your team. It’s important to remember that part of making a great team is being a great leader yourself. Time to get started.

Good Coding Standards For Faster Development

CodingStandardsCoding standards are a waste of time. If you agree with that statement, you’d probably have a lot of support from other developers who feel the same way. After all, programmers are smart people. They shouldn’t need someone watching over their shoulder telling them how to do their job, right?

Developers Rule, Or Should They?
A developer who says “don’t tell me how to do my job” may be fine in your organization. It just doesn’t work if you’re on my team. It tells me that the programmer cares more about doing his own thing than about the team or the customer. Because a standard will by nature disallow certain practices, it will definitely be an irritant. The key question for me is whether that irritation will result in a developer stand-off or will be accepted as part of the process for the good of the end product.

Skinning A Cat
“There’s more than 1 way to skin a cat”. While that’s true (having never done it myself, I’m guessing it’s true), it’s just not true here. A standard says “this is how we do it here”. It doesn’t mean that there are no other viable possibilities. In fact, the standard may not rank 1st in every developer’s opinion. The key is that the standard was pre-decided, which is an expensive process in terms of time. By simply implementing the standard, there’s a built-in time savings.

A Real-World Example
Let’s talk session variables. In a web app, these are the settings that store information specific to a user for that login (oversimplified, don’t judge). One particular project I remember had an abnormally large number of poorly implemented session variables, and we were starting to see bugs in our production code because of this issue. Specifically, we had code that resembled this: Session[“my_key”] = myNewKeyValue . This value was being set all over the place and meant something different depending on what part of the app you were using. That’s bad.

To fix the problem, I had to take some time and figure out how we should actually be using session variables in this project. I decided that there would be 2 types of session variables: session variables related to a single page and session variables that were related to the site. Those were the only options, and the names of the variables were required to match their scope (page or site). After the session variable mess was cleaned up throughout the project, we didn’t see the same type of bug. Problem solved. Standard implemented.

Coding Standard Overkill
If implementing a standard solves 1 problem, implementing 10 standards will solve 10 problems, right? Wrong! Before you go crazy with implementing all possible standards, you need to ask what problem each standard is solving. Your 10 standards may solve 5 problems, which means you’ve got 5 standards that do nothing but add overhead. Plus, remember that each standard is by nature an irritation to developers. Without a really good reason to put the policy in place, you’ve just added job stress for no reason whatsoever.

How Standards Speed Up The Dev Process
Think of an assembly line. Now think of how that same process would look if the product was being produced without the discipline of the assembly line. The end product would likely be different every time and there would be a lot of chaos. Only disciplined processes can safely be sped up. You can speed up the assembly line by tweaking parts of the process. Attempting to speed up the non-assembly line version only produces more chaos, more sub-standard products, and causes more frustration. While churning out code has more variation than an assembly line product would, the point is that having an undisciplined process, improvements cannot be made.

Getting Started
If you’re on board with the idea of implementing standards but don’t know where to start, ask yourself where your biggest problems are. Look at the types of bugs you’ve been fixing for 6 months. Listen to what your developers are complaining about. Come up with code samples that show the way you expect the code to look. Most importantly, start today. Coding standards that you’re planning to implement next week will probably never get implemented.

Stop Wasting Time – Start Thinking Small

SmallCarBigCar

A frequent mistake I find junior coders making is that they try to solve big, complex problems. They soak in detailed customer requirements, probably taking excellent notes, then hop right into Visual Studio (or whatever fuels your 20x dev speed) and start coding. Big mistake! They’ve just lost hours, days, or sometimes weeks by taking this approach. In fact, occasionally a dev will never finish the task. In this case, the power of thinking small improves performance by an infinite amount – going from an infinite amount of time down to pretty darn fast. Ok, enough selling, here’s how you think small.

Big Problem, Think Big Picture
This step is probably the easiest and most impactful of all steps of the process. Pretty much all complex programming assignments that I’ve ever had are able to be broken down into 5-10 steps (give or take). As important as your IDE is to the development process, it has no place at this stage. A piece of paper or notepad.exe are your best options. Think through the process, and break your big process down into 10 steps – logical steps, please. Your complex problem is now an order of magnitude smaller. Now break down each of your 10 steps into sub-steps. I’m telling you, this is basic, but “smart” developers skip this all the time.

Pseudo-code
Don’t let the name fool you into thinking this is a fake part of the process. The big steps you were breaking down above are going to get so basic that you find yourself writing a task that represents 5-10 lines of code. It’s at this point that you can open up your coding tool of choice. I’ve got good news though. Now that you’re in your IDE, you’re gonna fly. Using the breakout outline you did above, you’ve now likely laid out your classes, functions, child functions, etc. Because you wrote your plan in plain English (making an assumption about my blog readers here), you’ve got near-perfect function names. Take out the spaces and you’re set. Your final level of tasks can be comment headers, so stick a // , — , ‘ , /* , REM or whatever you need to in front of your lowest level comments.

Tempting Hammy, Very Tempting
You may think the right answer from here is perform a foreach(pseudoCodeBlock) { writeCode(); }
You’d be wrong. Ok, backing off my type A a bit here, you may be able to do it. You’re just a lot less likely to finish coding as fast as the way I’m about to divulge.

Minimum Verifiable Product
Yes, I just made that up, but the concept is solid. As fast as you can, get to the point where you can verify something, ANYTHING. At this point, your functions (at least most of them) should be in place. Maybe it makes the most sense to log something. Maybe it’s changing a color. Don’t care, it should just prove that you’ve got the basics down, and that you’re ready to move on to the next step.

Code-Test-Code-Test
At this point, I usually pick the easiest place to see results and code a function. Then I test and fix (notice I didn’t say refactor – if you thought refactor was the right word, look it up). Then I code another function, and another. Then I get adventurous and code a part where I can’t see results without coding a parent and a child function. Here’s the part that you’ll never hit with this technique – a logical brick wall. I’ll admit that there will still be brick walls occasionally because you don’t know the technology, but it’s not because you don’t understand what you’re going to do with your code.

Mixing In Source Control
As part of my coding and testing in small increments, as I get to a major victory point where I think I may want to return, I commmit to source control. How often I commit is proportional to the likelihood of breaking something in the next hour. I think of it like a game save point. If I may want to start from this state again, I’ll make a save point.

Full Disclosure
I’ve used this technique to the point where I can usually perform a number of these steps in my head (using a similar technique, I frequently got marked down on my physics homework). Here’s the deal. If you can save time by not methodically performing every last step I’ve outlined, that’s awesome. This works as a way to train your brain how to think like a 20x’r. Once you’re trained, move on to the doing part.

Keeping My Post Smaller
Since a ridiculously long blog post about keeping things smaller seems shady to me, I’m going to cut short on some of the other ways you should keep your start-to-finish dev process small. The final takeaway here is that in order to get faster, you’ve got to short circuit your craving to do more and force yourself to make micro-changes. Your code will look different, your final product will be more solid, and your boss will be happy to see how fast you start cranking out quality code.

The Secret Of 15

TechnicalBookStackMost of us live busy lives. Maybe we’ve got spouses, kids, and commitments at church. When I first introduce the idea of reading technical books to the geeks that get stuff done for me, it’s pretty common to get a response involving not having time. I get it. Let’s move on to the secret of 15.

15 What?
15 is the number of minutes reading per day that I want people to try to squeeze into their busy lives. I think that’s realistic, and I know from experience that people who have used this technique have seen success as a result.

The Goal – Clearly Stated
The goal is simple: progress your career. By progressing, I mean moving your career in the direction you’d like to go. I’ve had a number of non-programmers want to join the club to start coding (seriously, who wouldn’t want to join the club?). For some, it may be moving into management. It may be changing core technologies. Whatever it is that you could say “I think I’d rather be doing X.” This is pursuing X.

Guidelines
I’m a big fan of books, and while I don’t 100% get why everybody else isn’t wired like me, it’s still true that some people learn better other ways. Some of my guys and girls are more hands on. They can’t read about Hadoop. They’ve got to find a way to play with it. That’s a good way to spend 15. Basically, anything that teaches about fundamental concepts qualifies. Fundamentals meaning you’ll know how the technology is built, brick by brick. Most blogs, Youtube, and Facebook groups don’t cut it for me. They’re typically not focused enough and tend to cover edge cases instead of core concepts. Websites like Pluralsight or Trailhead from Salesforce are fine though.

Why 15 Works
According to Earl Nightingale, putting in an hour of reading per day about your field will make you one of the best in the world at your field after 7 years. Sweet! So why would I encourage 15? Isn’t an hour better? Yep, it definitely is, but an hour is too much time to mentally carve out for a lot of people. They’d never get started. That’s why 15 works – it gets you started. I’ve found it frequently the case that after 15 minutes, people get so excited that it turns into a half hour or a full hour. I can’t tell you how many times someone has been on the 15 program and has come in to work the next day knowing exactly how to solve a particularly hard problem because their 15 minutes got them thinking about ways to apply what they’ve learned. 15 minutes spent reading may turn out to be 30 minutes or an hour total per day of time spent thinking about what you’re learning.

Earning It
To become a 20x Developer, you’ve got to earn it. It doesn’t happen just showing up to work every day. It requires blood, sweat, and tears (or whatever the geek equivalent would be for those) to really become a faster programmer. It’s intentional effort with The Secret Of 15 being one of the best places to start.

Retrieving Parent Visualforce Remote Objects

Salesforce No SoftwareWhy Visualforce Remote Objects?
Salesforce recently rolled out Visualforce Remote Objects as a way to allow CRUD operations to Salesforce objects in a Visualforce Page without having to write code in a server-side controller.  While I don’t have a problem writing code in a controller to handle CRUD actions on an object, if I could skip that step, then why wouldn’t I?

Shallow Vals
Unfortunately, accessing parent objects, lookup, or child objects from a VisualForce Remote Object isn’t currently supported.  Back to SOQL in the controller?  That’s definitely an option, but with a little Javascript magic, we’ve got a good alternative.  Keep in mind that the only technology used for data access in the code below is Visualforce Remote Objects.  Pretty sweet.

Visualforce Remote Objects Setup

<apex:remoteObjects >
    <apex:remoteObjectModel name="Contact" jsShorthand="ContactRemoteObject" fields="Name,Id,AccountId">
    </apex:remoteObjectModel>
    <apex:remoteObjectModel name="Account" jsShorthand="AccountRemoteObject" fields="Name,Id">
    </apex:remoteObjectModel>
</apex:remoteObjects>

We need to set up remote models for getting both the main objects and the parent objects. In my case, I’m using the standard Salesforce objects Contact as the main object and Account as the parent object. I’ve assigned the fields attribute with the list of fields that I’ll be using on this page. As a little something special, my jsShorthand names are actually longer than the original object names. Don’t judge.

Page Layout

<h1>Visualforce Remote Objects Parent Example</h1>

<br /><br /><br />
<b>Name Starts With:</b> <input type="text" id="txtNameStartsWith" />

<br /><br />
<input type="button" onclick="loadContacts();" value="Load Contacts" />

<br /><br/>
<b>Contact List</b>

<ul id="contactList">
</ul>

Nothing fancy here. Functionally, I’ve got a filter textbox, a button, and an empty list that will hold my results. Obviously in a real implementation, you’d take the time to design a visually impressive page. Alright, let’s move on to the fun stuff.

Retrieve Primary Objects

<script type="text/javascript">

    var retrievedContacts;

    function loadContacts() {
        var objContactRemoteObject = new SObjectModel.ContactRemoteObject();
        objContactRemoteObject.retrieve({
            where: { Name: { like: document.getElementById('txtNameStartsWith').value + '%'} },
            limit: 100
        }, function(err, records) {
            processContactRecordsResult(err, records);
        })
    }
    
    function processContactRecordsResult(err, records) {
        if(err) {
            alert(err.message);
        }
        else {
            retrievedContacts = records;
            loadAccountsForRetrievedContacts();
        }
    }

</script>

This Javascript to get the primary objects should look almost identical to how you’d get any results using Visualforce Remote Objects. The biggest difference here is that when I get my Contacts back from Salesforce, I’m calling loadAccountsForRetrievedContacts() which will retrieve the parent Accounts. One other quick note, I’m caching Contacts in a Javascript var retrievedContacts. I’m usually a fan of fewer global variables, so if you accuse me of breaking my own rules, you’re probably right.

Retrieve Parent Objects

<script type="text/javascript">

    var retrievedContactAccounts;

    function loadAccountsForRetrievedContacts() {
        var objAccountRemoteObject = new SObjectModel.AccountRemoteObject();
        objAccountRemoteObject.retrieve({
            where: { Id: { in: getAccountIdListForRetrievedUsers() } },
            limit: 100
        }, function(err, records) {
            processAccountRecordsResult(err, records);
        })
    }
    
    function getAccountIdListForRetrievedUsers() {
        var accountIdList = [];
        
        retrievedContacts.forEach(function(contactRecord) {
            if (! arrayContainsValue(accountIdList, contactRecord.get("AccountId")))
            {
                accountIdList.push(contactRecord.get("AccountId"));
            }
        });
        
        return accountIdList;
    }
    
    function arrayContainsValue(arr, val) {
        for (var currArrayIndex = 0; currArrayIndex < arr.length; currArrayIndex ++) {
            if (arr[currArrayIndex] === val) {
                return true;
            }
        }
        return false;
    }

    function processAccountRecordsResult(err, records) {
        if(err) {
            alert(err.message);
        }
        else {
            retrievedContactAccounts = records;
            displayContacts();
        }
    }

</script>

This is the money code (never heard anybody use that phrase, but it could completely catch on). In loadAccountsForRetrievedContacts() , I’m getting all the parent Accounts for the Contacts we just retrieved. Essentially, I’m just building a list of all the Contact’s AccountId values. The part that took me the longest to get this working was figuring out that the In operator doesn’t like duplicate values in the list, so I’m filtering out any duplicate AccountId values. When the parent Accounts are returned, we hand control over to displayContacts() , which now has access to both the cached Contacts and Accounts.

Display Results

<script type="text/javascript">

    function displayContacts() {
        var contactListUl = document.getElementById("contactList");
        // clear previously loaded contacts
        while( contactListUl.firstChild ){
            contactListUl.removeChild( contactListUl.firstChild );
        }
        retrievedContacts.forEach(function(contactRecord) {
            var parentAccountRecord = getRetrievedAccountRecordById(contactRecord.get("AccountId"));

            var contactString = contactRecord.get("Name");
            contactString += " - Account:  ";
            contactString += parentAccountRecord.get("Name");

            var contactItemLi = document.createElement("li");
            contactItemLi.appendChild( document.createTextNode(contactString) );
            contactListUl.appendChild( contactItemLi );
        });
    }

    function getRetrievedAccountRecordById(accountId) {
        var foundAccountRecord;
        
        retrievedContactAccounts.forEach(function(accountRecord) {
            if (accountRecord.get("Id") == accountId)
            {
                foundAccountRecord = accountRecord;
                return;
            }
        });
        
        return foundAccountRecord;      
    }

</script>

If you’ve used Remote Objects in the past, this should look familiar. There are really only a couple lines different than normal. In the foreach Contact loop, the first thing we’re doing is to get the parent Account for the Contact using getRetrievedAccountRecordById() . In case you skipped over the name of the function, its only purpose is to find the Account using the Contact’s AccountId value. At this point, we have both the Contact record and the parent Account record available to do whatever we want to with them. Out of all the amazing things I could do with this, I chose to get the Account name. Boom!

Not That Hard
After reading through, you’re probably feeling kind of ripped off because I didn’t really do anything you couldn’t have already done on your own. True, but when I was searching for answers on how to get parent Visualforce Remote Objects, this would have at least given me a head start. From what I’ve seen, Salesforce is planning to make further improvements across their Remote Objects technology, so it wouldn’t surprise me if the approach I’ve taken is completely outdated in a couple releases. Good luck, and if you have any lessons learned as you’re using this technique, please post a comment so we can all benefit.

Download Visualforce Remote Object Parent Source Code

Technology Chasers

Bad Behavior Loop
Being in a technology field, the advice I’m about to give makes me feel kind of dirty, but it’s one of the easiest ways for developers to stop wasting time.  Stop changing technologies!  Or more to the real point, changing technologies is expensive – both in dollars spent and in developer time.  Unfortunately, in my experience, often the developers with the most potential fall into the new tech cycle the fastest with every project (probably every decent size task if they could) just because it got a mention on Twitter from a big name.

Nothing To Brag About

Here are a few reasons to consider putting the brakes on bleeding edge:

  • Paradigm shift – Everything from language specifics like short circuiting to specialized rules such as whether a user control is html encoded by default will cause either frequent Google searches on the front end of the dev cycle or bug fixes on the tail end.
  • Move as a team – The bigger the team, the harder it is to change anything.  Even with the brightest and best developers, there will still be a lot of information that has to be communicated and failures before lessons will be learned.
  • Loss of developer magic – One of my favorite developers I’ve every worked with talked about the magic that happened every time his fingers hit the keyboard.  In unfamiliar territory, that magic disappears for a while.  It only returns after developer dues have been paid in terms of dedicated time with the tool.
  • Bad news for end users –  Newer technologies tend to be buggy at first.  Not only that, with the latest-and-greatest, there may not have been time before product roll-out to make sure everything ran efficiently.  If it’s bad for the user, it’s probably not worth the change.
  • Decision for / decision against –  Spending time on something new means not getting even better at something you already know.  Honestly, it’s unlikely that a developer will ever exhaust all resources on one technology.  Picking an in-demand technology and doing a deep dive is a solid strategy.

/root Cause

I’m probably as guilty as the next programmer when it comes to wanting to change.  So why do we do it?  Because there’s not much difference between the average developer and a kid in a candy store with handfuls of cash.  Actually, now that I think about it, a dev shop is more like a bunch of kids in a candy store.  The only thing that distracts us from candy is…more candy.  Doing new stuff is why we got into programming in the first place, right?  Maybe, but for any developer looking to really make an impression, my philosophy is that making a ridiculously happy customer is a better career move than getting more play time at work.  Re-prioritize.  Career candy > tech candy.

When To Change

When is it time to make a move to a different technology?  Probably no big surprise, but there’s not a universally great answer to that question.  What I’d encourage is making an intentional effort to decide when is right for your organization knowing that there will be a significant cost involved.  Slower is probably smarter.

 

Any additional insight from fellow 20xers?  Big successes or big fails when making a switch?

Geek On A Mission

Geek Mission

The Big Idea

From industry research, we know that there are programmers out in the tech world producing code around 20x as fast as some other programmers with the same number of years of experience.  Being around programmers all the time, I’d say that 20x is low when you factor in more than just the typing component.  Finding these guys is a huge challenge, which means they’re likely to be worth their weight in gold (my weight in gold is currently around $3,002,624 USD).

If you haven’t gotten to 20x geek status just yet, tone down your OCD freak out for a sec.  I’ve got good news.  Nobody starts at that level.  After almost 15 years in IT, I’m more convinced than ever that dev speed is more about intentionally spending time practicing than a nerd-gift bestowed at birth.

Faster && Better

To be clear, I’m not going to be advocating pushing out lower quality code.  Actually, studies have shown that those who program faster end up producing higher quality code.  That means code that’s less buggy, more performant (yes, that’s really what we call it even if spellcheck doesn’t agree), and easier to read.

Foreign Languages

I’ve used mainstream languages like .Net and Java, so examples are likely to be in one of those.  Quick warning though, I’ve also started to pick up programming for Salesforce and Dynamics, so I reserve the right to use whatever I’m in the mood for at the time of post creation.

Ready For Takeoff

I’m excited to start, and hope you’ve got your seatbelt strapped on.  Let the techno-blogging begin.