Tips – LDNDeveloper

SQL Basics

Today, I am writing this blog because I did not have a chance to conduct the SQL training with the support team yesterday before I departed for a new adventure; I feel like I owe it to them to give them something. This is part one of the training session. This part is about SQL basics. Part two is about using patterns to gain efficiencies in your day-to-day work. Let’s start with part one: SQL Basics.

Andrew Pallant – A Strategic Leader in Engineering

Introduction

In the dynamic landscape of technology, effective leadership is crucial for driving innovation, fostering collaboration, and achieving organizational goals. As a Vice President of Engineering, I have had the privilege of witnessing Andrew Pallant’s remarkable journey—a journey that exemplifies technical excellence, strategic vision, and unwavering commitment to customer success. In this article, we’ll explore Andrew’s impact, his role in shaping engineering teams, and the principles that guide his leadership.

I flipped over Flipp

I don’t often promote apps and products, but my wife found an app that makes shopping more efficient.

If you have an Apple or Android phone and you like deals or price matching, you must try Flipp ( http://www.flipp.com ). My wife “clips” the deals on her iPad and it immediately shows up on my iPhone or iPad under “clippings. At the grocery store checkout, I just show them my clippings and the price nicely decreases saving me money. The synchronization is a nice touch in it self, but this app also has an awesome search feature that allows you to search for a product and it shows all the flyers that it is published in. This app is its weight in gold. One stop shopping at No Frills and I have most of my savings as if I drove from store to store.

Life has become simpler with Flipp

Currently on my Bookshelf

This past month ( December 2012 ), I have been doing a lot of reading and research in to books that I want to read. Continue reading Currently on my Bookshelf

Be Kind to Those You Meet

You never know when you meet someone what they will be to you in your life. You may meet them in a service club, be a customer of yours, be a friend or an in-law. You just never know when that argument with the sales associate be something that bites you down the road. Continue reading Be Kind to Those You Meet

When a Developer Leaves

To start; I am not saying this is me, but I did talk to a few developers for research.

Employers are often left scratching their heads when a developer leaves. The unfortunately truth is when one leaves another often follows not to long after. It is very hard to understand why the first developer left let alone the second or third. I believe as a employer, team lead or VP, you should know some of the “WHY” for a better understanding of a developer’s behavior. I admit we are a strange brew of employees.

Developers like to be challenged and appreciated. When the challenge is gone, so is the developers will to continue. Developers need to know that they will not be doing the same thing day in and day out. They really need to mix things up a bit. They need responsibilities, new tasks and freedom to try new things on their own. They also need to know they have the company’s support to continue education, and not just a pat on the back. Try to hire from within the team before you look for that new manager. Sometimes you have the perfect leader within the company already.

Developers also have a keen sense of appreciation. They do not need a thank you, or a pat on the back from their employer all the time, but they definitely know when they are being exploited and taken advantage of. More and more companies are introducing foosball, video games and fun activities to show their developers that they can have fun and are appreciated. It is the little things that go a long way. A BBQ in the summer with some good laughs and keep the spirits a little brighter.

These are just brief explanations of why a developer may leave a company, but very rarely is it just for more money. There is often more to it. An exiting interview may shed more light on the “WHY”, but more likely you will never know. An observation that I have made recently; there is a real misunderstanding of junior developers. Junior developers are ones that leave their company the most. Junior developers leave because they are treated poorly by senior staff, paid unfair salaries, no or little vacations and benefits and simply they often do not feel apart of the team. Junior developers add value to any team for a couple reasons.

Successorship for senior developers
Brings new ideas and techniques to the table
They still absorb new information at a fast rate

Why would other developers leave shortly after?
Loyalty is often a factor. Developers are social creatures who form a tight community that is often hard to break into. They often congregate at bars and coffee shops after hours or on breaks to share and implement ideas. This form of interactions creates a tight bond. If a company hires one developer, it is not uncommon for that developer to want to take a few of his trusted colleagues with him. This is a practice that shows the tight bond and trust between the development community. Developers like to work with people they know and trust. It is also becoming a more common practice for the new employer to try to take an entire team of developers that are linked by a common employer or group. This helps create a stronger team.

What Not to Say to a Developer
I was once told that I would never be able to advance out of my position because I was too good at it. These words are like knives going into the heart. A developer likes to be challenged and advance through their career like anyone else in the workforce. Developers are often known to put their heart and sole into their work; often giving 110% of themselves. Advancement is often equal to being similar to being appreciated and/or trusted. Nothing kills a employee’s will to continue faster than words. Chose your words wisely.

Strange Creatures
Developers are strange creatures. They are creatures of habits ( generalization ) and often do not like change. Exception here is developers often embrace changes as in new technology and ideas. When I say they do not like change, they do not like to

move homes, place of work, parking spots, watering holes, etc. They like their every day habits and routines. When a developer leaves it is often a big decision and they did not take it lightly. It is often not a personal reflection on the company, but rather a personal reflection of themselves.

Quick Points

Find out what other companies are doing to keep their developers engaged and happy
Talk to your developers often on a personal level
Create a trust with your developers. Do not give them a reason to not trust you.( Example: monitoring internet usage and emails )
Give them freedom. Allow them to occasionally work on projects of interest ( Google often does this and then makes money from the side projects )
Let them use social media to keep connected and build the communities. You do not want your developer to feel isolated. Non-techie people often do not understand a developer
Do your hardest to create real expectations, and not push crazy hours. Developer burnout is rampant in small companies
Do your best not to call your developer all hours of the night and every day when they are on vacation. You would not want this for yourself.
Treat your developer as you would want to be treated

Publishing Using VisualStudio

I have often had the glorious opportunity to watch someone try to deploy a project by picking compiled libraries that they had thought had changed. Every time they deployed by using this method, their live project would not run. When they run their project on the development machine, it runs no problem. This confuses the developer to no end resulting in a multitude of profanities.

This is a bit painful to watch. I really do not understand why developers do not deploy by using installation packages or deployment methods provided by their development environment.

Today, I had offered to deploy the project for them and used the VisualStudio deployment utility. This was a web-based project so it was very easy. The deployment wizard walks you through the process starting at where you would like to deploy to. The deployment results in only deploying the files necessary to run the program or website. I had learned this principal while working for a London company; ICINITI.

ICINITI would use a packaging tool to deploy products to customer machines including websites. Their projects would often automate part of the process including site setup, run batch files and deploy other required files. Deployment to customer’s computer systems would go pretty quick. Sometimes it was so smooth the customer was able to conduct the deployments themselves.

Today’s deployment took about 5 minutes or less. I had later demonstrated how and what I had done. I believe this will be used a little more often as a deployment technique.

Seven Tips to Project Success

Before starting any project, you should know what you are doing before you start. Ask your users, create focus groups and research every detail. By asking your users you will know what your users will need to do their jobs and what they are expecting. Focus groups will provide feed back of what direction you should be taking the project by telling you what they think will work or not work. Both users and focus groups should be used through out the project in order to keep the project on track. Lastly, research your project to ensure you have all of the information and regulations written down so that all can review, understand and agree. Know every bit of your project.

After done your research and you have talked to the users, it is time to formalize a project plan. First outline all requirements of the projects so that all parties can understand. You should include charts, graphs and diagrams where applicable. Now, add to your formal project plan a break down the individual pieces into tasks, people resources and time to complete each task. By now you should really know what you need to complete the project
and it is time to list anything that need to complete the tasks outlines, concerns that you have for doing the project and any other special notes.

Sit down with all stakeholders of the project including users and management and discuss the formal project plan. Ensure everyone understands the pan, what it will take to do the plan and that anything new will move the timeline out. Get management to sign-off on the plan indicating the understand and agree with everything.

Do not stop using the users and focus groups, they will ensure you stay on task and that you are not going off on the wrong track. They will discover issues before the project is done. Do not get defensive when the discover issues.

Follow-up with your people resources on a weekly basis to ensure that they are still on task. Encourage them to come to you sooner than later with issues.

Test, Test, Test

Deliver the final project to management and users by doing a proper presentation, training and sign-off sessions. Without proper training and presentations you will have user errors and a very busy support desk. If this is a contract project ensure that your company that you are working for know the terms of support and training. Sign-off sessions is just a indication that you are done as per your plan which was also signed off.