Professional Development Archives - Page 4 of 4

How a Senior can Help a Junior Developer

Senior developers have a responsibility to help those who are new to the profession. We are the one group of people that the junior developer can turn to after college. Essentially the college gave the new developer 2 years of education, a piece of paper and tossed them out to sink or swim.

I personally do not like to see anyone sink. I believe no matter what the skill set is, a person could be a little better if a helping hand is given. I am not suggesting a babysitter, as no one really wants that. I am suggesting an open door, an open mind and a little patience. Juniors will make mistakes and they will often be a little cocky thinking they know it all coming out of school, but we need to remember their minds are still in the stage of learning.

Juniors can learn much more at their stage in life. Their minds are like sponges and soak in the good and bad habits and knowledge that we share with them. The best thing we can do for them is to teach them everything we know, encourage them to do extra learning on their own and to listen to them. When I last managed a small team, I asked for a weekly report, which consisted of:

1. What are they working on?
2. Where are they on the schedule of tasks?
3. What obstacle have then encountered? Are they still stuck, if not how did they over come it?
4. What is one thing they learned new this week?

During our weekly meeting, I would get one or two of the developers to talk about either the obstacle or their new found knowledge with the rest of the team. This way all new and old developers had a chance to share and learn from each other.

In summary, help them learn in every aspect. Listen to their ideas and new found knowledge. Have an open door for questions. Lastly; be cautious of your bad habits.

Do Not Get Boxed

As a developer, it is important to look around and experience new things, as it helps you to stay sharp and marketable. This doesn’t mean that you need to quit your job. Just do not get boxed in as single purpose developer.

It is important not to be just a developer of one kind. Do not just be a PHP Developer, DotNet Developer, or a SQL Developer. Strive to be more than what you are currently doing.

As an example; when I was just starting out as a developer I had two unique jobs. First job was a Visual COBOL Developer and the second job was a Factory Automation Integrator specializing in database and Visual Basic integrations to Allen-Bradley PLC. If I had allowed myself to be boxed into either one of these developer types, I would not have had the opportunities to do more. With the Factory Automation Integrator, I would probably be pumping gas as the firms I used to work for and see around are mostly gone now and who the heck is using Visual COBOL anymore?

As a Web Developer working for a web development firm, you may be asked by a customer to do a mobile application or a windows application to complement their other work you may have done.

I strive every day to learn something new. I learn it until I know it well enough to be productive. I also practice what I have learned in the projects I work on in my spare time. .

In my current job I am a Web Developer, SQL Developer, Windows Developer, Mobile Developer and a Support Specialist. I have also worked where I had a single focus as a Web Developer at a web development firm, but I stretched myself to do business needs analysis. It is important to be forever evolving as a developer. Just don’t speak of the new technologies. Learn the new technologies and know and practice what have you have learned.

Eleven Items That Makes a Developer Great

Here are a few items that makes a software / web developer great:

Updated to twelve items thanks to some input.

Knowing they are not perfect
Listens to business needs
Always evolving by striving to do better
Never hides a mistake, but acknowledges and learns from it
Does not blame the user for the error
Always tries to learn something new
Makes notes
Listens to teammates
Does not blame the previous developer
Willing to dive in and do the work no matter what
Ask questions when they do not know [ Shawn Adamsson rTraction @late2game ]
Thinks and plans before coding. Know where you’re expected to go and plan the path to get there carefully [ Shawn Adamsson rTraction @late2game ]

How to deal with a non-technical boss

We have all had bosses at one time or another that we had to deal with who was not technical in nature. Often we find it frustrating because we do not speak the same language and we do not know how to deal with each other. We as the employee can take the first step in understanding each other.

How to Speak?
You need to transform your speech into a language that your boss will understand. Knowing full well that your boss will not understand tech terms, programmer’s language or computer-speak; an alternate language is required. It is a bit of an art to transform your speech into something else. My father-in-law does it very well, but I am still learning. I like the idea, if my wife has trouble understanding it; it may be too techie. It is best to learn business terms that mean the same as tech terms. You also need to shed the technology details and implement business details. Chances are the non-technical boss will not care how it is done, but they will care about timelines, money and training.

How to Process?
Your non-technical manager will throw out business terms. They will tell you what they want using their business language. They may try to throw out some tech terms, but often they will use them incorrectly. The best approach is to make notes, and ask questions. Forget how you will go about accomplishing the task, but instead find out the details of the requirements.

Example: If they say they need a calculator to calculate how much to ship a box, ask questions like:

1. How is it done now?
2. Ask about rounding rules?
3. Ask if they do it by weight or size or both?
4. Ask if there is a matrix of postal codes?
5. Where do they get their rates?

Remember; they really do not care how you will program it. They just want it usable and for it to function correctly. Take your notes and ask your questions. Take everything back to your office and transform the details into a project and programming plan. Write out the formulas, draw out your user interface and write out your timelines for approval.

How to Act?
Do not get frustrated. Remember they are just as confused by you at you are of them. It is not their speciality to be technology. Treat them as a customer; it will help you respect them. Make lots of notes and repeat back to them what you hear. Use non-offensive language and body gestures. Sometimes drawing pictures will help both parties to understand.