I’d like to become a Development Team Leader

Hopefully most will have actually considered the change of role and be looking for new challenges and ways to contribute more to their chosen profession. However, for some this is an automatic response to a question that is particularly difficult to answer in an industry with no clear career path. For others it’s simply a way to move up the pay scale.

Before you start talking to your manager or applying for your next job it’s worth considering what you’re getting yourself into. Depending on where you work there will be different definitions of a Development Team Leader (DTL). To put this post in perspective this is my interpretation,

A Development Team Leader is someone who owns the technical delivery of a solution. They need to understand the business drivers behind the project and be able to lead a team of Developers to realise these drivers in working software.They are (IMHO) the central player in a project team and need to maintain excellent communication with all members of the team from Client to Developers and everyone in between.

I tend to distinguish between what I call a Senior Developer (SD) and a DTL. A SD is someone who still does the tasks of a developer but does them really well and has lots of experience. They don’t tend to have the added responsibilities of a DTL. DTL’s often (but not necessarily) have a SD background.

Assuming you’re a developer this is what I reckon your job entails.

Let’s face it the life of your average developer is focused around cutting code. Sure you might have daily Scrums or other team meetings to attend but your main focus is writing software. And you love it!

When you become a DTL you work balance is up for a bit of a change.

Other than the coding slice don’t place to much attention on the relative weights of the pie slices - suffice to say you won’t be zoning out for 8 hours a day to your favourite tunes - you’re the one that gets interrupted, you’re the one putting out the fires and making sure the wheels are oiled. Your head is on the line if the solution doesn’t meet expectations or is delivered late. You have some responsibilities and influence now.

Coding - don’t worry, you still get to practice your craft but just not as much as you used to. There are now lots of other things that you need to be involved in too.
Documentation - even with the increasing popularity of Agile methodologies and a move away from excessive documentation there are still times when (technical) documentation is necessary - and guess what? You will be first in line to do it.
Meetings - if you thought you were in lots of meetings as a developer then you ain’t seen nothing yet. Depending on the size of the project you are involved in you will be the main participant in a wide variety of meetings. Whether it’s a meeting with the client, the delivery team, the PM, you are the one with the most knowledge of both the requirements and the implementation of the solution.
Communications - beyond official meetings you will also be heavily involved with communicating to others via emails, issue tracking software, the phone and face to face catch ups on progress. It’s a bit of a cliche but good communication skills really are the key to succeeding in many professions - and for any leadership role it’s essential.
Delegation - because of your other duties it’s an essential part of your role to be able to delegate work to others. Someone once told me that the job of the DTL is to make themselves redundant - an apparent contradiction to your pivotal role on the project but one that sums up the responsibility you have to ensure the project moves forward even when you can’t personally be there to solve an issue. The more you delegate responsibility to others in your team the more involved and productive they become. Don’t try and do everything yourself.
Mentoring - part of reason for delegating tasks to others is to provide them with opportunities for personal growth and development. Mentoring carries this idea further and is a key part of your role. No-one is an island and you must be prepared to share your knowledge with others. As an aside you should also be prepared to learn from your team - DTL’s who think they know it all are usually wrong and always disruptive to the morale and effectiveness of the team.

How to Become a Development Team Leader?

As Development Manager to a team of incredibly motivated and talented individuals I often have conversations that begin,

    Hey Tokes, I really want to move my career to the next step and want to know what I can do to become a Development Team Leader.

My response,

    Act like one!

That’s right, it’s that simple. Wherever possible take it upon yourself to assume some of the tasks that would normally be expected of a DTL. The more DTL skills you display the more likely others will see you in that light and give you the opportunity to perform the role for real. Whatever you do, don’t sit quietly behind your desk with the headphones on and expect someone to recognise your leadership potential and tap you on the shoulder - it won’t happen. Similarly don’t assume that because you’re a technical genius that becoming a DTL is the natural next step in your career or something you deserve in recognition of your talents. The skills of a DTL go beyond the technical and require you to have other skills like great communication, the ability to delegate, confidence, being level headed, acting in a professionalism manner…

So what can you do I hear you ask? You’re only a developer, right? Wrong, the act of developing is only part of what you have to offer.

Let it Be Known - it seems obvious but you should let your manager/PM/peers or anyone else who will listen that you want to become a DTL. Don’t be a nag about it but just plant the seed in people’s minds.

Understand the Big Picture - one of the big differences between a good developer and a great one is their ability (or interest) to understand the big picture. They understand the business goals and pain points the system is addressing. They understand the entire solution, not just their part of it. They understand how the code they are writing benefits the client and the solution as a whole. They understand the client and what is important to them. They understand that the code is a means to an end and that project success will be primarily measured by client satisfaction.

Ask Questions - I love working with people who ask questions. It shows you are attempting to understand things thoroughly. It shows you’re not afraid to question why something is being done in a certain way. It show’s, that as a DTL, I’m not the only one thinking things through and that there’s more chance the team is on the right track. Understanding the Big Picture is crucial to being able to ask the right questions.

Don’t Wait to Be Asked - while you should always be on top of the tasks delegated to you, don’t stop there. Be hungry like a wolf, hunting out ways in which you can add value, help others and identify issues. Do not wait for your own DTL to ask you to do something, try and always be one step ahead without, of course, second guessing their authority.

Be Approachable - DTL’s are often the go-to guys (or gals) but they’re also pulled away from the team to attend meetings etc. Be approachable (i.e. take off the headphones now and then!) and aim to be the one people seek out when the DTL’s away - this is a great sign that you have the respect of the team. If you’re doing the things above this will be a natural consequence and shouldn’t require you to do anything specific.

Stay Calm - what was it that Mr Kipling said? "If you can keep your head when all about you Are losing theirs… you’ll be a DTL my son!". Software development can be a stressful business. Look around at DTL’s you respect - guaranteed they will be the level headed ones, the ones that don’t let the pressure get the better of them (or at least are good at hiding it!)

1) Ajax is an idea, not an acronym

While Ajax commonly is spelled out as Asynchronous JavaScript and XML, the full name is not entirely appropriate because it oversimplifies the history of the technology and the implementation options that lie at its heart. More exactly, Ajax encompasses the idea that Web applications can be built to opt out of the typical post-wait-repeat cycle used in server-side-focused Web applications. Ajax lets Web applications move to a more responsive, continuous, but incremental style of updating. Ajax provides users a richer, more interactive way of experiencing the underlying Web application. This goodness for the user might mean that more monitoring and security oversight might be required of network professionals, as well as, potentially, server and network alterations.

2) It’s really all about JavaScript

Ajax applications are written in JavaScript and usually rely on the XMLHttpRequest object for communications, which is making its way through the World Wide Web Consortium process. Because, like many Web technologies, it now is only an ad hoc industry standard, notable differences can be found in various browsers’ implementations of it. It’s also possible to use other data transport mechanisms — with and without widespread industry support — with Ajax applications, including traditional frame and image-cookie methods, as well as the use of binary bridges to Flash or Java.

Regardless of the transport approach used by the developer, Ajax has raised JavaScript to a more important position within a Web application than it previously held. JavaScript now is responsible for important data-collection, communication and consumption duties, so it no longer can be treated as a second-class Web technology without serious repercussions.

Developers who think the JavaScript technology is toxic can try to avoid the language by having a tool or framework generate it from some other language like Java (Google Web Toolkit, for example), or hide the code behind components or tags (such as with .Net or Ruby). At the end of the day, however, JavaScript still will be in the application. It’s better to understand the language and embrace it directly, because if you are going to use Ajax, you ultimately are using lots of JavaScript.

Ajax is intertwined with the network, so bad code is going to mean lots of troubleshooting by network administrators, as well as developers: The bottom line is to encourage good, network-aware coding! The same organizational "rules and tools" — coding standards, testing regimes and source-code control — that are in place for other languages must be applied to JavaScript to ensure that Ajax applications are supportable and robust.

3) XML is not required

Despite the "x" in the acronym, Ajax does not require XML. The XMLHttpRequest object can transport any arbitrary text format. For many Ajax developers, JavaScript Object Notation or even raw JavaScript code fragments make more sense as a data format, given that JavaScript is the consuming environment. For direct input into documents, other developers may favor raw text or HTML fragments. Still others will use such data formats as the less-known YAML markup language or such old standbys as comma-separated values.

Of course, it is possible and certainly reasonable to use XML, but it is far from required. Using binary formats for uploading files is not supported yet by the XMLHttpRequest object, but considering that Flash uses a binary format called Action Message Format, it is likely that similar features will be found in Ajax applications soon enough. You should know which format is being passed around the network, because it isn’t always XML. Also, make sure you can analyze the format for performance and security.

4) Plan for an increase in HTTP requests

The most obvious issue for the network administrator supporting Ajax applications is that the architectural programming pattern has changed the network utilization of Web applications from a batch-like, somewhat infrequent response of a few hundred kilobytes, to a more continuous exchange of smaller HTTP responses. This means that network-bound Web and application servers may find themselves even busier than before. What Ajax will do to your server and network utilization certainly will depend on how the application is built — make sure your developers understand the network impact of their applications.

5) Optimize Ajax requests carefully

Web applications should adhere to the network delivery principle of sending less data, less often. That doesn’t mean that this principle is widely followed by developers, however. Fortunately for the network, HTTP compression of Ajax responses can reduce response size and is supported in all modern browsers. Because of dynamic compression’s overhead, however, speed may not improve much if responses are indeed relatively small. This means that it would be wise for network administrators to turn on compression on their Web server, but they need to understand that with Ajax applications, their gains won’t be as big as with traditional Web applications.

To send data less often, we generally would employ caching. Most Ajax implementations can be openly hostile to caching, however, given certain assumptions made by browsers regarding not re-fetching URLs during the same session. Rather than work with caching, many Ajax developers will work aggressively to defeat caching via the header setting or URL uniqueness.

It is possible to address caching concerns with a client-side Ajax cache written in JavaScript, but most Ajax libraries do not implement such a feature. Network professionals should show developers the benefit of caching, because Ajax probably will benefit more from that than from compression.

6) Acknowledge the two-connection limit

Ajax applications are limited by HTTP to two simultaneous connections to the same URL. This is the way the HTTP protocol is designed, not some browser bug or limitation. The good news is that it keeps many Ajax developers from swamping a server accidentally, though Microsoft’s Internet Explorer 8 is supposed to go well beyond the limit. Chatty Ajax applications can be trouble, and with browsers changing the rules, network administrators need to keep a close eye on the number of requests made, and work with application developers to avoid employing such design patterns as fast polling or long-held connections.

7) Watch out for response ordering

With traditional Web applications, the network effects of TCP/IP communications — such as the lack of order in which individual HTTP responses are received — generally are not noticed by developers or users. The base unit, the HTML document, is received before other objects, and it then triggers the request. Any subsequent request triggers a whole new base document, thereby guaranteeing order. Ajax takes such implicit ordering away, however, so that an application dependent on proper sequencing requires a response queue. Ajax frameworks, however, are not consistent in acknowledging this network concern. So, again, make sure Ajax application developers understand such network-level concerns.

8 ) Acknowledge the effects of eliminating "Layer 8" error correction

For years, users have been correcting Web-delivery quality by reloading pages or pressing the Back button. Simply put, users doing this help mitigate network problems because errors occur generally at expected moments between page paints. With Ajax, however, application failure is no longer that obvious. Worse yet, users often are misinformed about errors, because the simple, animated-GIF spinning circle provides little information about the true status of the request.

Developers are at a loss because many libraries aren’t effective at acknowledging that timeouts happen, retries must occur, and server and data errors crop up. JavaScript diagnostics showing communication and code errors are rarely in place on the client side, so blissful ignorance is the norm. More application-level monitoring is required for administrators to support Ajax properly.

9) Old security threats get a second exposure

If you listen to the pundits, Ajax may appear to produce more attack surface, but it really isn’t any less secure than traditional Web-application development environments, because the HTTP inputs to the trusted server side are the same — headers, query string and message body. If implicitly trusting client-side code and entered data is not verboten already in your Web development group, however, Ajax may push things in that direction.

Cross-site scripting (XSS) isn’t a vulnerability new with Ajax; it is just more common, especially if an application allows state data to be manipulated with JavaScript. HTML input should be disallowed in most cases, and HTTP Only Cookies should be applied immediately to reduce cookie hijacking and other attacks via XSS.

Cross Site Request Forgery likewise isn’t new with Ajax, but if your application developers aren’t checking the HTTP Referer (sic) header and managing sessions properly within Ajax applications, you’ve already been open to it, although it might be worse now.

Hackers, like developers, now are more interested in using and abusing JavaScript, which increases the potential for exploits. Network professionals should make sure developers are aware that client-side code can be manipulated even with obfuscation in place, so data inputs should always be filtered and sanitized, Ajax or not.

10) Abide by same origin for your protection

On the positive side of security, JavaScript’s same-origin policy (SOP) is fully enforced in an XMLHttpRequest-based Ajax application. This policy makes sure that scripts cannot talk to domains outside of those from which they are issued. From the developer’s point of view, this can be quite annoying because it means that pages served, for example, from ajaxref.com can’t talk to a URL hosted on www.ajaxref.com; even if it is the same machine, it isn’t the same exact domain. DNS equivalency doesn’t matter here; it is a string-check employed by the SOP.

The SOP will severely hamper a developer’s ability to perform some Web-service efforts on the client side as well. Clearly the best approach is to use a proxy on the server to bounce requests to other servers and combine the results. However, many Ajax developers attempt to break the same-origin restrictions. Using the <script> tag as a transport instead of the XMLHttpRequest object introduces dangerous trust assumptions, and that leads to the origin of much of the concern about overall Ajax security.

Now, with such browsers emerging as Firefox 3 and Internet Explorer 8 employing native cross-domain request facilities, there is certain to be more trouble on the horizon. As is the case with Java’s security-sandbox concept, SOP restrictions are introduced just to keep developers from destroying security. Go around such safeguards with extreme caution.

Watch what you wish for

With Ajax, rich-application widgets will win a project, but bad plumbing may sink it. If the promise of a rich Ajax application is delivered in a network environment that is occasionally fragile, users will become disillusioned with the perceived instability of the application regardless of its slick interface. To enable desktop-like quality, network professionals must educate Ajax developers about certain network and security fundamentals and provide a solid and constantly monitored delivery platform that includes client-side diagnostics on JavaScript functioning and network performance from the user perspective. Users regularly see rich Web applications done right — like those coming from Google, for example — so anything less is a risky endeavor. 

Shouldn’t we all be performing at the same level? Of course not, we’re not sewing buttons on an assembly line. We’re using every bit of our intelligence to create something that we can only begin to understand.

    * I think logically. Computers don’t care how you feel, and your opinion doesn’t matter. All that matters is if you write your code exactly the way the computer dictates.
    * I constantly look for better ways of doing things. I subscribe to a good number of development blogs. I alone cannot always come up with the best way to solve a problem, but somebody somewhere probably can.
    * I read books. Joel says that most programmers have stopped reading books. What a shame. Blogs are great for snippets, but it’s rare that they cover a topic well from start to finish. Blogs are the ADD version of books.
    * I don’t stop thinking about problems and how to solve them through automation. Sometimes I’ll wake up in the middle of the night, and I can’t get back to sleep until I write some code that I can’t get out of my head.
    * I have side projects that I think are interesting, and give me a chance to try things that I might not want to try on my production code at work. Yes, my side projects distract me at work, but the knowledge I gain pays back the time I lost.
    * I have a tech blog. I suggest all developers start a blog and give back to the community. If you solve a problem, we want to hear about it! At the very least, it will give you an opportunity to formalize your ideas, which will either reinforce them, or make you realize you were wrong. You might also get some great feedback.
    * I try to prove myself wrong (aka objective). Everyone wants to be right. I try to prove myself wrong when appropriate. One of the hardest things in the world for a developer to do is say that the code they just spent a week writing is useless. Maybe it is, don’t fight it, work with it.
    * I keep up with the latest technologies, and force myself to try them.
    * I have a relatively good understanding of how the computer hardware and software works. I’ve met too many developers that barely know how to turn on a computer.
    * I’m great at writing Google queries.
    * I’m not just in it for the money. I actually enjoy what I do. I had a job interview where the guy that would have been my boss told me a story about how he was brought in off the street and thrown into managing their software projects. When the software industry starts getting rough, who do you think is the first person to go?
    * I’m sympathetic to the users pain. If I can share their pain, I’ll want to fix it and prevent it.
    * I realize my code will never be perfect, so I try to make it testable and modular. I set up processes that try to minimize the effect of my human error.
    * I don’t think Microsoft is evil, and I don’t think they’re a saint. They’re a big company. Some of the stuff they write is crap, some is amazing. The same is true for any other company out there.
    * I learn from my mistakes. I try to put at least 2 checks in place to avoid any past mistakes. If one check fails, I’ll have the other.
    * When I’m asked to solve a problem, I think above the problem, and determine if it’s a problem that even needs solved.

There’s no shortage of stories about Google’s newly launched App Engine, but almost all of them get it wrong — because they compare the new service to Amazon’s EC2 and S3 services (AMZN).

If the Silicon Valley echo chamber wants to make up a competitor for AppEngine, its proper correlate (by a whisker) is Facebook’s F8 platform. If you must cram this new service into a pigeon hole, think of App Engine as the Facebook Platform for the grown-up web.

Why isn’t App Engine like EC2 & S3? Constraints, constraints, constraints:

* Google is going the run-time environment route, not the scalable, “put anything you want in a box and we’ll scale it” route that EC2 provides. Case in point: We could run the BricaBox Platform on EC2 by tailoring our own environment (the LAMP stack) and booting it up on Amazon’s servers. We could not get BricaBox running on AppEngine without re-writing in Python, ditching functionality which needed outside libraries or languages, or relational databases.

*Google is not trying to provide pure utility here — they are trying to provide utility tethered to their infrastructure. While EC2’s initial investor pitch was “we have this scale and want to monetize unused portions of it,” many smart people called them out for what they were really doing: creating a new business based on the concept of utility computing, which had nothing at all to do with their core infrastructure at Amazon.com (i.e. they weren’t using EC2 or S3 for their needs).

*Google is clearly looking to have as many of these apps tie into existing pieces of Google’s infrastructure: everything from the authentication systems (Google Accounts only!) to code libraries (most open source or API accessible code from Google is written in Python and ready to run in their environment) is based around this infrastructure and will be based around this going forward.

So, why is App Engine more like the Facebook Platform 3.0?

* App Engine is designed for lightweight apps.

* App Engine apps are wrapped around Google’s existing userbase and communication infrastructure (Gmail), creating a more organic Social Ecosystem for Google.

* App Engine is way more interoperable with the rest of the web than Facebook apps, though still built around a proprietary stack.

* The first App Engine apps will be huge! The next ones will have just as much trouble emerging from the murky waters of the web as any other apps.