How does one build a successful technical career?

THE other day, I met a bright young engineer in MindTree and asked him what his ambition was. He was very clear. "I want to be an architect". My next question to him was, what does he read? He looked surprised and then replied that he does not read much outside what appears on a computer screen. My next question to him was whom all does he admire in MindTree among the three best architects? He named the predictable three. Then I told him what the fundamental gap was between him and the best three. It was about the ability to make intelligent conversation about any subject under the sun - a capability borne out of serious reading habits.

The next thing I asked him

to do was to poll these three on what were the six books they had read last. The result was amazing. The three named eighteen books in all - of which at least six were common. Ninety percent of the books had nothing to do with information technology. The exercise proves a key point - to be a great nerd, one has to have inteerests outside writing code. However, many engineers think that the path to a great technical career is about technical skills alone.

Long back, Bell Labs conducted an interesting study - closely watching the common characteristics among a group of technical professionals who rose to the top. The exercise revealed nine key factors outside just technical competence that differentiated brilliant technical folks from the masses. The study was conducted by Robert Kelly of Carnegie Mellon and Janet Caplan of Williams College. As I see the Indian industry today, I think the study done at Bell Labs remains relevant in every detail.

The Bell Labs engineers who did extremely well for themselves - as they progressed in their career, showed the following qualities that differentiated them from their peers: taking initiative, cognitive ability, networking, leadership, teamwork, followership, perspective, organisation savvy and show-and-tell capability. Let us look at each of these and see what lies underneath.

1) Taking initiative

This is about accepting responsibility above and beyond your stated job. It is about volunteering for additional activities and promoting new ideas. None of these will jump out as apparent as a young engineer gets in to her first job. She will tend to think that her career progress is really dependent only on the ability to write code. The concept of initiative begins by looking for technical and other opportunities in the organisation and volunteering for them. The idea of volunteering is little understood - both by organisations and individuals. In the days to come, it will gain increasing prominence in our professional lives.

Initiative is also about two other things - dealing constructively with criticism and planning for the future. The latter is a function of many things - a good starting point is to start mappinng the environment, learning to understand how the future is unfolding and then stepping back to ask, how am I preparing myself?

2) Cognitive abilities

The concept of cognitive development is about understanding the interplay of technology and trends in how they are getting deployed. It is also about recognising the business eco-system in which technology works. It is about situational understanding and consequence thinking. The importance of consequence thinking is very critical. It asks us to look beyond the immediate deliverable of a task and it is about asking who will be impacted by my work, what is the end state? People in our industry just think in terms of modules and seldom ask where is it going, who is my customer and more importantly - who is my customer's customer? Cognition is a key faculty that determines how much we are able to read patterns, make sense of things. Refining cognitive skills helps us to go beyond stated needs of our customers to explore unstated needs.

3) Networking

We tend to think of networking in a social sense. As one grows higher in life, we are often as powerful as is our network. Building a professional network requires us to step out of the comfort zone to look at whom can I learn from. Quite often, and more as one progresses in life, the learning has to come from unusual sources. At MindTree, we expose our people to social workers, architects, graphic designers, teachers, people who lead government organisations, leaders from client organisations. The interesting thing about benefiting from a network is that it works like a savings bank. I need to deposit in to it before I withdraw. We all have heard about how important internal and external knowledge communities are. Again, in MindTree, we encourage people to belong to 26 different knowledge communities that run on a non-project based agenda and are vehicles of learning. These create networking opportunities and open many doors.

4) Leadership

Next to networking is development of leadership skills. Many technical people associate it with "management" and shy away from developing key leadership skills like communication, negotiation, influencing, inter-personal skills, business knowledge, building spokespersonship and so on. Take for instance negotiating as a skill. Imagine that you are an individual professional contributor. Why should you learn to negotiate? Tomorrow, your organisation becomes member of a standard body and you have to represent the organisation as a technical expert. You will find yourself needing to negotiate with powerful lobbies that represent a competing viewpoint or a rival standard. Unless you have honed your capability alongside your hacking skills, you will be at a complete loss. Yet, you do not discover your negotiating capability one fine morning. You need to work on it from an early stage. Negotiating for internal resources is becoming another critical need. You can choose to remain an individual professional contributor but from time to time, you have to create mind share in the organisation where resources are limited and claimants are many. Establishing thought leadership is another key requirement of growth and independent of whether I want to be a technical person or grow to be a manager, I need to develop as a leader who can influence others.

5 ) Teamwork

Our educational system does not teach us teamwork. If you ever tried to solve your test paper "collaboratively" - it was called copying. You and I spent all our school and college life fiercely competing to get the engineering school and seat of our choice. Then comes the workplace and you suddenly realise that it is not individual brilliance but collective competence that determines excellence. Collaboration is the most important part of our work life. Along with collaboration come issues of forming, norming, storming, performing stages of team life. Capability to create interdependencies, capability to encourage dialogue and dissension, knowledge sharing become critical to professional existence. All this is anti-thesis of what we learn in the formative years of life. Add to it, our social upbringing - our resource-starved system tells us to find ways and means to ensure self-preservation ahead of teamwork. In Japan, the country comes first, the company (read team) comes next and I come last. In India, it is the other way round.

6) Followership

The best leaders are also great followers. We can be great leaders if we learn and imbibe the values of followership. Everywhere you go - there are courses that teach leadership.

Nowhere you will find a business school teaching you followership. Yet, when solving complex problems in life, we have to embrace what is called "situational leadership". I have to be comfortable being led by others, I must learn to trust leadership. Many people have issues reporting to a test lead as a developer, or being led by a business analyst or a user interface designer. In different parts of a project life cycle, people of varied competence must lead. I must be comfortable when some one else is under the strobe light. I must have the greatness to be led by people younger than I, people with a different background or a point of view. That is how I learn.

7 ) Perspective

This is the hardest to explain. It begins with appreciating why I am doing what I am doing. Quite often, I find people having a very narrow view of their tasks; many do not see the criticality of their task vis-à-vis a larger goal. So, a tester in a project sees his job as testing code or a module designer's worldview begins and ends with the module. He does not appreciate the importance of writing meaningful documentation because he thinks it is not his job or does not realise that five years from now, another person will have to maintain it.

I always tell people about the story of two people who were laying bricks. A passer by asked the first one as to what he was doing. He replied, "I am laying bricks".
He asked the second one. He replied, "I am building a temple". This story explains what perspective is and how the resultant attitude and approach to work can be vastly different.

8) Organisational savvy

As technical people grow up, they often feel unconnected to the larger organisation. Some people develop a knack of exploring it, finding spots of influence, tracking changes, creating networks and in the process they learn how to make the organization work for them. The organisation is not outside of me. If I know it well, I can get it to work for me when I want. Think of the difference between one project manager and another or one technical lead from another.
One person always gets the resources she needs - the other one struggles. One person knows who is getting freed from which client engagement and ahead of time blocks the person. One person reacts to an organisational change and finds himself allocated to a new project as a fait accompli - another person is able to be there ahead of the opportunity. Larger the organisation, higher is the need to develop organisation savvy. It begins with questioning ones knowledge about the larger business dynamic, knowing who does what, tracking the work of other groups, knowing leaders outside of my own sphere and a host of other things. Importantly, it is also about tracking what the competitors of the organization are doing and keeping abreast of directional changes.

9) Show and tell

This is the bane of most Indian software engineers. We all come from a mindset that says; if you know how to write code, why bother about honing communication skills? Recently, we asked a cross section of international clients on what they think is the number one area of improvement for Indian engineers? They replied in unison, it is communication. Show and tell is about oral and written communication. Some engineers look down upon the need for communication skills and associate it with people who make up for poor programming prowess. It is the greatest misconception. Think of the best chief technology officers of companies like Microsoft, Oracle, IBM Global Services or Sun. Their number one job is evangelizing.

If they cannot forcefully present their technologies, nothing else will matter. So, every engineer must pay attention to improving the ability to present in front of people, develop the ability to ask questions and handle objections. In a sense, if you cannot sell the technology you create, it has no value. So, building salespersonship is a key requirement for technical excellence.

The foregoing points are not relevant if you have already filed your first patent at the age of eighteen.

Everyone else, please take note.

Read More...

Summary only...

Introduction

As a developer, the .NET framework and Visual Studio present many choices for choosing the right architecture, from placing the data access code directly in the UI through datasets and data source controls, to creating a data access layer that talks to the database, all the way to creating an n-tier architecture approach that consists of multiple layers, and use data-transfer objects to pass data back and forth.

If you’ve ever wondered why you should use layers and what the benefits are, this article is for you. This article delves into the use of layers and how they can benefit any application.

What is a Layer?

A layer is a reusable portion of code that performs a specific function. In the .NET environment, a layer is usually setup as a project that represents this specific function. This specific layer is in charge of working with other layers to perform some specific goal. In an application where the presentation layer needs to extract information from a backend database, the presentation would utilize a series of layers to retrieve the data, rather than having the database calls embedded directly within itself. Let’s briefly look at the latter situation first.

Two-Tier Architecture

When the .NET 2.0 framework became available to the world, there were some neat features that allowed the developer to connect the framework’s GUI controls directly to the database. This approach is very handy when rapidly developing applications. However, it’s not always favorable to embed all of the business logic and data access code directly in the web site, for several reasons:

• Putting all of the code in the web site (business logic and data access) can make the application harder to maintain and understand.
• Reusing database queries in the presentation layer often isn’t done, because of the typical data source control setup in the ASP.NET framework.
• Relying on the data source controls can make debugging more difficult, often due to vague error messages.

So in looking for an alternative, we can separate the data access code and business logic into separate “layers”, which we’ll discuss next.

The Data Layer

The key component to most applications is the data. The data has to be served to the presentation layer somehow. The data layer is a separate component (often setup as a separate single or group of projects in a .NET solution), whose sole purpose is to serve up the data from the database and return it to the caller. Through this approach, data can be logically reused, meaning that a portion of an application reusing the same query can make a call to one data layer method, instead of embedding the query multiple times. This is generally more maintainable.

But the question is how is the data returned? Multiple frameworks employ different techniques, and below is a summary:

• ADO.NET – Built into the .NET framework, ADO.NET contains a mechanism to query data out of the database and return it to the caller in a connected or disconnected fashion. This is the most common approach to working with data, because it’s already readily available. See more at: http://en.wikipedia.org/wiki/ADO.NET.
• Table Adapters/Strongly-Typed Datasets – Strongly-typed datasets and table adapters provide a similar means to querying the data through ADO.NET, but add strong-typing features, meaning custom objects are generated for you to work with. See more here.
• Enterprise Library – Enterprise library Data Access Application Block provides a flexible way to connect to databases of multiple types, without having to know anything about that database, through an abstract approach. See more at: http://msdn2.microsoft.com/en-us/magazine/cc188705.aspx (read part one first).
• LINQ-to-SQL – LINQ to SQL is an ORM tool that uses a DataContext object as the central point to query data from the database. See more here. (read parts one through eight first).
• Auto-Generated Code – Tools like CodeSmith Studio automatically generate the code for you based upon a database schema. Simply writing a script to output the code you want to use and the backend is generated in a short amount of time. See more at: http://community.codesmithtools.c om/blogs/tutorials/archive/2006/02/13/nettiers.aspx.

Most (if not all) options above take advantage of the CRUD (create, read, update, or delete) operations that databases support, so all of that is available as shown above. There are plenty of resources online to help you get started. To see an overview of some of the options, please read this.

Business Layer

Though a web site could talk to the data access layer directly, it usually goes through another layer called the business layer. The business layer is vital in that it validates the input conditions before calling a method from the data layer. This ensures the data input is correct before proceeding, and can often ensure that the outputs are correct as well. This validation of input is called business rules, meaning the rules that the business layer uses to make “judgments” about the data.

However, business rules don’t only apply to data validation; these rules apply to any calculations or any other action that takes place in the business layer. Normally, it’s best to put as much logic as possible in the business layer, which makes this logic reusable across applications.

One of the best reasons for reusing logic is that applications that start off small usually grow in functionality. For instance, a company begins to develop a web site, and as they realize their business needs, they later decide to add a smart client application and windows service to supplement the web site. The business layer helps move logic to a central layer for “maximum reusability.”

Presentation Layer

The ASP.NET web site or windows forms application (the UI for the project) is called the presentation layer. The presentation layer is the most important layer simply because it’s the one that everyone sees and uses. Even with a well structured business and data layer, if the presentation layer is designed poorly, this gives the users a poor view of the system.

It’s best to remove as much business logic out of the UI and into the business layer. This usually involves more code, but in my mind, the excess time (which ranges from minimal to moderate, depending on the size of the application) pays off in the end.

However, a well-architected system leaves another question: how do you display it in an ASP.NET or windows application? This can be more of a problem in ASP.NET, as the controls are more limited to the type of inputs they can receive. If you use certain architectures, like passing datasets from the data to the presentation layer, this isn’t as much of a challenge; however, the challenge can come with business objects that support drill-through business object references.

Why Separating Logic Is Useful

You may wonder why it is important to move as much logic outside the presentation layer and into the business layer. The biggest reason is reuse: logic placed in a business layer increases the reusability of an application. As applications grow, applications often grow into other realms. Applications may start out as a web application, but some of the functionality may later be moved to a smart client application. Portions of an application may be split between a web site and a web or windows service that runs on a server. In addition, keeping logic helps aid in developing a good design (sometimes code can get sloppier in the UI).

However, there are some caveats to this: it takes a little longer to develop applications when most of the logic resides in the business layer. The reason is this often involves creating several sets of objects (data layer and access code, plus business objects) rather than embedding it in the application. The extra time that it takes to do this can be a turnoff for some managers and project leads, especially because it often requires you to be knowledgeable about object-oriented programming, more than most people are comfortable with.

Although embedding code in the UI is easier, in most cases I don’t believe it’s the best approach. A layered approach is often a better approach because it pays dividends down the road. This is because as more and more code is developed, the following happens:

• Code is copied and pasted frequently, or code is reused in classes that could easily be moved to a business layer.
• Code that is very similar is often copied and pasted with slight modification, making duplication harder to track down.
• It’s harder to maintain; even though applications with business objects are larger applications, they usually are structured better.
• Code is harder to unit test, if unit testing is available at all. Web applications and windows forms projects are hard to use unit testing with.

A good architecture is often harder to implement, but is easier to maintain because it often reduces the volume of code. This means that hours spent supporting an application are reduced.

Distributed Applications

Using a separation of layers can aid in development of distributed applications. Because the code is broken up into layers, a layer that facilitates the use of remoting or web services can be added to the project, with a minimal amount of work.

Development Techniques

When developing a business object architecture, it’s good to know about the many design patterns that are out there. There are many websites, blogs, and books related to the subject of design patterns. One of the more well-known books on the subject is titled “Design Patterns,” whom the authors are often referred to as the Gang of Four.

Another useful development technique is called Refactoring, or improving the quality of your code by making small changes to the way it works. This involves moving code into a method, or moving a method from one object to another, in a systematic, logical way. Martin Fowler has written a great book on this subject, called “Refactoring, Improving the Design of Existing Code.” There are plenty of books on the subject; this one is the source that helped me to understand refactoring the most.

There are also tools on the market that can help you refactor in a faster way. One of those tools is Resharper by Jet Brains, which looks for a lot of code patterns and refactors them in a way that is useful. Some of the other refactoring tools that I heard about are Refactor Pro by DevExpress (free for VB.NET and ASP.NET), Visual Assist X by Whole Tomato Software, and Just Code by OmniCore.

Conclusion

This article reviewed the use of layers in an application, and discussed the fundamentals of their use. It also discussed the purpose of each layer, why using layers is important, and some other techniques useful for developing applications.

Read More...

Summary only...