Mentor Entry Level Developers In Easy 7 Steps

Every Organization needs to mentor the entry level developers to attain success in their future endeavors. So, if you are the one who is given an opportunity to teach and train your new people then following tips will be good for you.

Not every developer can become a good mentor so if you think you are not up to the task you should straight forward say NO to your employer otherwise you will end up wasting your time and alienating a promising new developer. But if you are up to the task then read the following 7 tips on how to successfully mentor the entry level developers.

1. Mentoring should be your priority

I think the key ingredient in a successful mentoring relationship is giving the relationship priority above anything other than an emergency. It is the inability to give the relationship priority that makes true mentoring scenarios so rare. If you don’t make the mentorship a priority, the new hire quickly senses that she is not important. She also quickly figures out that, when she goes to you for help, she is slowing you down from attending to your “real” priorities. The end result? She doesn’t seek you for help, and she tries to do things on her own. Basically, you’re no longer her mentor.

2. Define a Clear Road map

I’ve seen a number of mentoring programs sink because there is no plan. Someone is hired, and a more experienced developer is assigned to show that person the ropes. The experienced developer wasn’t told about this new mentoring role until 9:05 AM on the new hire’s first day. The would-be mentor takes the new hire on a tour of the building and introduces her to a few other teams — and that’s the extent of “the ropes.” The only thing the new employee usually learns is where to find the kitchen. You need to have a game plan with set goals (for the new hire and the mentor) and a list of topics to cover; otherwise, you’ll both feel lost and give up before you even start.

3. Be tolerant of mistakes

Working with entry-level developers can be frustrating. They are not familiar with writing code in a real-world environment with version control, unit tests, and automated build tools. Also, they may have been taught outdated habits by a professor who last worked on actual code in 1987. Often, entry-level developers do not realize that the way they were taught to approach a problem may not be the only choice. But if your reaction to mistakes is to treat the developer like she is stupid or to blame (even if she is being stupid or is truly at fault), she probably won’t respond well and won’t be working with you much longer.

4. Assign appropriate projects

One of the worst things you can do is to throw an entry-level programmer at an extremely complex project and expect her to “sink or swim.” Chances are, the programmer will sink; even worse, the programmer will add this project to her resume, and then she will run out of there as fast as she can just to get away from you. On the other hand, don’t create busywork for the programmer; let her work on nagging issues in current products or internal projects that you never seem to have time to address. Once you gain confidence about what the programmer can accomplish, then you can assign a more difficult project.

5. Give and accept feedback

You can’t successfully navigate a ship in the middle of an ocean without a compass. Likewise, the new employee will not achieve her goal of becoming a productive member of the team without knowing where she has been and where she is going. This means you need to give feedback on a regular basis, and the feedback needs to be appropriate. For instance, being sarcastic to someone who made an honest mistake is not helpful. Feedback has to be a two-way street as well; you need to be listening to them to find out what their concerns and questions are, and address them.

6. Listen to the new employee’s ideas

Entry-level developers have a lot less built-in prejudices and biases than experienced developers. Sometimes the saying “out of the mouths of babes” really applies. A number of times in my career, I’ve seen a less-experienced employee point out an obvious answer that all of the more experienced employees overlooked. When you treat a new hire as a peer, it raises their confidence and makes them feel like part of the team.

7. Treat the developer with respect

Just because someone is entry-level, it doesn’t mean that her job is to refill your coffee or pick up your lunch. She isn’t rushing a sorority — she’s trying to break into the development business. If you disrespect the developer, she might leave or go to HR about your behavior (and maybe still leave).

Leave me a comment and share your thoughts. Also please Subscribe to our RSS for latest tips, tricks and examples on cutting edge stuff.

Why on earth you need Agile Development?

If you are a startup company or you are looking to build a global team across the continents for your product but you don’t want to end up with a mess you need Agile Development.

Agile methodologies generally promote: A project management process that encourages frequent inspection and adaptation; a leadership philosophy that encourages team work, self-organization and accountability; a set of engineering best practices that allow for rapid delivery of high-quality software; and a business approach that aligns development with customer needs and company goals.

There are various questions which comes to mind when you try to implement Agile methodology. I have tried to list down few basic question and answer below

Q. Why do you think agile is better than some of the more traditional methods out there?

The major benefits come from a greater focus of quality, discipline, working closely with business stakeholders and on delivering working software on a regular basis. It’s just best practices from the real world.

What are some of the agile methodologies?

At the methodology level there are things like extreme programming (XP), scrum — a project management methodology, agile modeling — for modeling and documentation, the open enterprise process — a basic combination of the XP, scrum, agile modeling, rational unified process (RUP) which is more of a full development methodology and crystal clear.

The agile method attracts a fair amount of criticism. Why is this the case?

The reason there is a lot of criticism is that a lot of people don’t understand what’s going on, they don’t know what they’re looking at. There’s a lot of misinformation out there which gets repeated.

People really are threatened by this, because part of the agile message is that you have to produce, you have to add value in a visible and measurable way and a lot of people from the traditional world really don’t add value and they know it. Sometimes, people think that no proper documentation is followed but that’s a myth.

What is the biggest challenge of agile?

The biggest challenge with agile is cultural differences. It’s not really a technology issue or a domain issue. People have these excuses to not change, because change is hard.

It’s not a technology thing, but it is a culture thing. You have to choose more discipline. One of the big cultural challenges in the traditional community is that they confuse bureaucracy with discipline. Bureaucracy is bureaucracy and discipline is discipline. Those are two different things and we need to get away from that. So if you’ve got this culture around this bureaucratic rigor, filling out forms and doing checklists, it’s going to be hard to move towards something quality-focused, value-focused like agile.

What would be the best way to transition into agile?

A couple of things. First, minimally you should do some pilot projects. Just because this is working for a lot of other people doesn’t mean its going to work for you. You really do need to get you feet wet.

Then after that, the challenge becomes [that] you’ve got to roll it out across the organization. That’s where things get harder. Now the entire organization needs change.

What is the the testing process in agile?

A technique that gets talked about a lot is test driven development. In test driven development (TDD) you write enough code to fulfill that test. This is an incredibly good practice, but it requires significant discipline, it requires training and you have to be allowed to do it.

There is a lot more testing going on by agilists then by non-agilists. It’s still not perfect, so we need to get better at that.

TDD is equivalent of testing against the specification. The assumption there is that your stakeholders are able to identify the requirements. We know that’s a false assumption. They’re not good at defining their requirements and it’s just not human nature. As a result, TDD can only be as good as what you’ve been told to do.

You’ve got to counteract that risk and the way you do that is by having an independent test team running in parallel, that’s doing more complicated forms of testing. They’d be doing security testing, performance testing, usability testing and exploratory testing.

Does agile requires more skill and experience?

It requires more discipline, almost always that translates into more skill and more experience, there have been cases with the people fresh out of school are doing very good at agile.

I would be more than happy if you can add more questions and answers. Leave me a comment and let me hear your opinion. If you’ve got any thoughts, comments or suggestions for things we could add, leave a comment! Also please Subscribe to our RSS for latest tips, tricks and examples on cutting edge stuff.

Popular Open Source Version Control systems

Version Control System (VCS) may seem foreign cocept to few designers but it is widely used in developers community arround the world. Version control system gives you power to work with multiple people (developers, designers) on the same code. Revision control is an excellent way to combat the problem of sharing files between co-workers. You don’t have to upload your files, email files so that other co-worker use if you are using version control.

Designers and developers can both benefit from using revision control systems to keep copies of their files and designs. You can instantly browse previous “commits” to your repository and revert to earlier versions if something happens.

This article reviews some of the top open source version control systems and tools that make setting up a version control system easy.

SVN

svn.jpg

Subversion is probably the version control system with the widest adoption. Most open-source projects use Subversion as a repository because other larger projects, such as SourceForge, Apache, Python, Ruby and many others, use it as well. Google Code uses Subversion exclusively to distribute code.

Because of Subversion’s popularity, many different Subversion clients are available. If you’re a Windows user, Tortoise SVN is a great file browser for viewing, editing and modifying your Subversion code base. If you’re on a Mac, Versions is an elegant client that provides a “pleasant way to work with Subversion.” Xcode is Apple’s developer environment and Subversion client that ships with Leopard on a Mac.

SVN Resources


CVS

cvs.gif

CVS is the grandfather of revision control systems. It was first released in 1986, and Google Code still hosts the original Usenet post announcing CVS. CVS is the de facto standard and is installed virtually everywhere. However, the code base isn’t as fully featured as SVN or other solutions.

The learning curve isn’t too steep for CVS, and it’s a very simple system for making sure files and revisions are kept up to date. While CVS may be an older technology, it’s still quite useful for any designer or developer for backing up and sharing files.

Tortoise CVS is a great client for CVS on Windows, and there are many different IDEs, such as Xcode (Mac), Eclipse, NetBeans and Emacs, that use CVS.

CVS Resources


Git

git.jpg

Git is the new fast-rising star of version control systems. Initially developed by Linux kernel creator Linus Torvalds, Git has recently taken the Web development community by storm. Git offers a much different type of version control in that it’s a distributed version control system. With a distributed version control system, there isn’t one centralized code base to pull the code from. Different branches hold different parts of the code. Other version control systems, such as SVN and CVS, use centralized version control, meaning that only one master copy of the software is used.

Git prides itself on being a fast and efficient system, and many major open-source projects use Git to power their repositories; projects like:

GitHub

has recently helped establish Git as a great version control system, providing a beautiful front end for many large projects, such as Rails and Prototype. However, Git isn’t as easy to pick up as CVS or SVN, so it’s much harder to use for a beginner.

github.jpg

Git Resources


Bazaar

bazaar.jpg

Bazaar is yet another distributed version control system, like Mercurial and Git, that offers a very friendly user experience. It calls itself “Version control for human beings.” It supports many different types of workflows, from solo to centralized to decentralized, with many variations in between.

One of the main features of Bazaar is the fine-grained control you’ll have over the setup. As shown with the workflows, you can use it to fit almost any scenario of users and setups. This is a great revision control system for nearly any project because it’s so easy to modify. It’s also embeddable, so you can add it to existing projects.

Bazaar also has a strong community that maintains things like plug-ins and lots of third-party tools, such as GUI software to add a graphical interface to the system.

workflows_gatekeeper.jpg

Bazaar resources:


Mercurial

mercurial.jpg

Mercurial is another open-source distributed version control system, like Git. Mercurial was designed for larger projects, most likely outside the scope of designers and independent Web developers. That doesn’t mean that small development teams can’t or shouldn’t use it. Mercurial is extremely fast, and the creators built the software with performance as the most important feature. The name “mercurial” is an adjective that means “Relating to or having characteristics (eloquence, swiftness, cleverness) attributed to the god Mercury.”

Aside from being very fast and scalable, Mercurial is a much simpler system than Git, which is why it appeals to some developers. There aren’t as many functions to learn, and the functions are similar to those in other CVS systems. It also comes equipped with a stand-alone Web interface and extensive documentation on understanding Mercurial if you have been using another system.

Resources for Mercurial


LibreSource

libresource.jpg

LibreSource is a Web portal used to manage collaborative projects. It’s based on Java/J2EE and is more a set of visual collaborative tools to help facilitate projects and teams. While the other systems discussed so far have been designed more on a “command line” level, LibreSource is centered more on tools that don’t have a big learning curve.

It has built-in features such as Wiki pages, forums, trackers, Synchronizers, Subversion repositories, files, download areas, drop boxes, forms, instant messaging and more. Think of LibreSource as a collaboration hub for project development.

LibreSource is perfect for the developer or designer who doesn’t want to learn lots of technical jargon and wants to focus more on communication with the project’s members. Just install the package and start collaborating, without facing much of a learning curve.

montage.jpg

Resources for LibreSource


Monotone

Monotone is the baby of the distributed revision control bunch. While many of Monotone’s peers focus on performance, Monotone places higher value on integrity than performance. In fact, it can take quite a bit of time for a new user of Monotone to simply download the initial repository due to the extensive validation and authentication required.

Monotone is fairly easy to learn if you’re familiar with CVS systems, and it can import previous CVS projects. However, it’s not quite as popular as other version control systems.

Monotone Resources


Version control Tools

  • QCT GUI commit tool
    A version control commit tool that supports Mercurial, Bazaar, Cogito (Git), Subversion, Monotone, and CVS.
  • Meld is a merge and diff tool that allows you to compare two or three files and edit them in place, while updating automatically. It works with CVS, Subversion, Bazaar and Mercurial.
  • Push Me Pull You is another GUI for distributed version control systems. It works with Mercurial, Git, Bazaar and Darcs.

Version Control Resources

Coutesy: Smashingmagazine: Shout me your experiences with the above applications their pros and cons. If you like this post kindly subscribe to our RSS for free updates and articles.

Creating an IT policy that works

When it comes to building and implementing an IT policy, no quick-fix or one-size-fits-all solution will adequately serve your needs. Every business is different, and the approach taken to meet objectives and/or ensure compliance will vary from one environment to another, even in the same industries. But you can take advantage of certain best practices to increase your odds of crafting and implementing a policy that employees will support and that will help protect your organisation.

Executive support

For starters, no policy will succeed without the basic buy-in from senior leadership. Senior executives, directors, and managers should be asked to provide input and some form of approval to the policy. Obtain a clear statement of support before you start creating the policy and continue to keep senior management educated and involved as it is written. When the policy is ready for implementation, request that management formally present it to your organisation, stressing its importance.

Consensus building

As you begin formulating a policy, you should involve all interested parties in the discussion of its establishment by creating a committee. Your committee should consist of the owner of the policy, subject matter experts, frequent users of the policy, and representatives from groups affected by the policy. You may also want to consult specific groups within your particular organisation, such as Human Resources, Financial, and Legal. These groups can make recommendations based on the impact of the policy on the organisation as well as on its viability and legitimacy. This will ensure the policy you develop is fully understood by everyone concerned and that it has their backing once it’s implemented. That broad base of support is one of the best assurances for policy success.

Policy contents

Although policies vary from organisation to organisation, a typical policy should include a statement of purpose, description of the users affected, history of revisions (if applicable), definitions of any special terms, and specific policy instructions from management.

Make sure everyone has a clear understanding of the purpose of the policy. Are you creating this policy because you have to be in compliance with some ruling? Are you trying to cut down on costs or create additional savings? Are you ensuring liability will not be placed on the company?

Creating a uniform policy format to ensure that information will be presented to the reader in a consistent manner is paramount for policy success. A uniform format will make the policy easier to read, understand, implement, and enforce. Keep the scope of your policies manageable as well. Consider making separate, smaller polices that address specific needs.

The language of your policies must convey both certainty and unquestionable management support. Remember, you’re setting policy, not describing standards. A standard would, for example, define the number of secret key bits that are required in an encryption algorithm. A policy, on the other hand, would dictate the need to use an approved encryption process when sensitive information is sent over the public Internet system.

Standards will need to be changed considerably more often than policies because the manual procedures, organisational structures, business processes, and information system technologies change much more rapidly than policies. You can reference standards within a policy and modify that standard as the technology or compliance requirements change.

After you roll out a policy, you may see many examples of inappropriate use or violations, but it’s difficult to anticipate them. So it’s important to have catch-all clauses within your policies, such as:

  • “Viewing or downloading offensive, obscene, or inappropriate material from any source is forbidden.”
  • “The storing and transfer of illegal images, data, material, and/or text using this equipment is forbidden.”

Research and preparation

In drafting your policy, you will want to research related issues both inside and outside the company. Some common areas to research include:

  • Company policy library (if you have one)
  • Forms and documents required to develop or complete the policy: request forms, legal documentation, etc.
  • State and or federal laws that are relevant to your policy
  • Similar policies at other businesses

One of the biggest mistakes many companies often make when they begin designing policies is to create guidelines and restrictions without any understanding of how the company’s business actually works. Although there’s always going to be a factor of inconvenience with any security policy, the goal is to create a more secure environment without making things overly difficult or hard to understand for the people having to use the resources the policy is trying to protect.

Policies made outside the company’s business model will begin to become circumvented over a period of time and the overall environmental state can become worse than before the security measures were implemented. So make sure part of your research involves developing a solid understanding of business processes so that your policy can work with them, rather than against them.

Policy reviews

Even after you’ve finished drafting or updating a policy, the job is not complete. The policy should be reviewed by legal counsel to ensure that it complies with state and federal laws before it’s finalised and distributed to employees. Further, you should review the policies on a regular basis to make sure they continue to comply with applicable law and the needs of your organisation. New laws, regulations, and court cases can affect both the language of your policies and how you implement them.

Most experts suggest a thorough review of your policies at least once a year and the use of a dedicated notification system/service to keep employees informed of changes. And when revised policies are introduced, you should formally distribute and thoroughly explain them to all employees.

Policy pointers

  • Consider holding (depending on the size of your company) a series of meetings that involves all interested parties.
  • Do not fill policies with “techie” terms. Polices must be written in layman’s terms or the concepts may be lost on the end users.
  • Set out what behavior is reasonable and unreasonable and determine procedures for dealing with specific abuses.
  • Try to keep polices to the point. Long written polices are difficult to read and comprehend, and users may be confused or simply give up on trying to understand them.
  • Agree upon a framework for policy review. Usage and technology may change, so you need to be flexible and adapt the policy when it is required.
  • Decide, define and mandate “what” is to be protected.

Done right…

Well-crafted policies show that an organisation and its management are committed to security and expect employees to take it seriously. Such policies provide an overall security framework for the organisation, ensuring that security efforts are consistent and integrated rather than ad hoc or fragmented. A good, regularly reviewed policy can be both an effective employee relations tool and a helpful defense against lawsuits. In contrast, policies that are poorly drafted or misapplied can decrease efficiencies and create roadblocks for normal business activities. Invest the necessary amount of time and effort to make sure your policies are solidly built and properly implemented.