As a computer nerd, I’ve used a number of different operating systems for a number of different reasons.  One of my favourite Linux operating systems is Ubuntu.  I like it for its ease of use, its great UI and a number of smaller reasons that are too numerous to list.

One of the things I hate about most Linux OS’s is the fact that the backspace button is used to go up in any documents.  Now, I know I’m just used to the Windows way of things but I find it one of the biggest nusances when moving to a new operating system.

Below are a few steps on how to fix Firefox in Ubuntu (and probably other operating systems) to get the backspace button to go back in history instead of going up the page.

1. Type about:config into your browser
2. Find browser.backspace_action
3. Change the value from 2 (or any other number) to 0

Once you’ve done the steps above, your browser will now function like it would in Windows with the backspace button going back in history instead of up the page.

If you have any other tips or tricks for us, please feel free to post them in the comment section.

Have you ever thought to yourself “I haven’t coded in so long, I really need to” but then did something else instead? This is called programming procastination (PP), and every developer will face it at least once in their career.

I get programming procrastination a lot when I’m trying to finish up my pet projects or even something to do with work. I don’t know why I don’t want to program sometimes but here are a few things I do to get me back into the programming mind:

1. Just Start Programming

Forcing yourself to program is on of my favourite ways to defeat PP. Its sometimes hard to just start programming but I generally lock myself in my room, and set a specific goal to reach. Generally the goal will be small to start out with; finish this method or class. Once I’ve started to program, the willingness flows back and I’ll stay for a few hours.

Just starting to program can help the creative juices flow, but this is the hardest step in my opinion.

2. Discuss Tactics with Another Developer

Talking with other developers is another way to get past programming procrastination. When you talk with other people it puts you into the mindset of a developer. This often is enough for me to get me past programming procastination because it gets me thinking about programming.

Talking tactics can help you figure out a problem that may be stopping you from programming or a complex algorithm. I generally talk to Alex when I’m stuck and can’t think of what to code.

3. Set a Specific Time to Start

This one is a little like just starting to code. When you give yourself a specific time to start coding it forces you to get into the mindset of a developer. If you know you’re going to sit down at 8pm and code something your mind will start to think like a developer and hopefully you’ll get past programming procastination.

4. Read Your Development Books/Blogs

Reading your favourite book or blog can help you get past programming procastination as well. Whenever I don’t feel like programming I go though my RSS reader and read some of my favourite development articles. It really helps put me in the programming mood. Dust off your favourite book or fire up your RSS reader and read whatever development stuff you want.

There are a number of ways to get past programming procrastination. The above four points are just a few that I use, but what I really want to know is how do you get through programming procrastination? Do you do any of the things I do or do you have your own ways? Feel free to drop us a line in the comment section below.

I’m a big believer of the fact that developers need to be comfortable in order to produce at their highest potential. While this includes such things like a relaxed dress code, and an ergonomic and comfortable work space, a good work environment is what is most important.

Have Fun

Knowing that your day holds the potential to be fun makes it much easier to get up and come in to the office every day. Work is no longer a dull place to be, but a place you actually enjoy being in.

We do a lot to make sure that we can have fun at work. We have low-walled cubicles, so everyone can see everyone, which encourages communication and joking around throughout the day. For lunches and overtime breaks, when they happen, nearly everyone in the department has a Nintendo DS, and we’ll play multiplayer games for 20 minutes or half an hour.

It’s a great way to give your brain a bit of a break from your work and have fun with your co-workers.

Competitions

Hold competitions or contests that are open to anyone in the office to join. We typically run sports pool, especially during the playoffs. Charity fundraisers are big for us too. We recently held a “Toss and Rock” fundraiser. The main idea is to wear a t-shirt from your favorite band, play rock music for the day and compete in the paper airplane tossing competition.

The competition was simple, build your own airplane, and throw it into a box with a hole one foot across cut in it (we made it look like a ring that was on fire), that’s suspended 18 feet away, 10 feet off the ground. You got 2 throws for 5 bucks.

We ended up raising over $800 for a local charity that day, and everyone had a blast.

Put some thought into what would work to make your office a fun place to be. Try some of it out, it’ll help improve moral, and possible change some peoples’ attitude about work.

On his blog, Steve Rowe shares a story of an employee who claims to be done their work, but by Steve’s standards is not. Steve puts this down to a difference in opinion of the word ‘done’.

“The problem stems from the fact that we rarely define the word. It is assumed that everyone shares a definition but it is rarely true. Is a feature done when it compiles? When it is checked in? When it can run successfully? When it shows up in a particular build? All of these are possible interpretations of the same phrase.”

Now, I completely understand the issue that Steve has had here, but I don’t agree that it simply comes down to a different definition of the word done. Done is done. When all of the requirements for the task are complete, the task is done.

Clear and purposeful documentation of the application that is to be built, outlining features and requirements will help show the developers what work needs to be completed prior to a task being done.

Define the task

The ultimate responsibility falls on the manager. A manager should be outlining their requirements for a task, or project, that the developer can follow.

Ideally this wouldn’t be a unique, per task requirement, but rather a general procedure that defines each task. This helps automate most of the processes and would then only require the manager if there is a unique or new situation.

My point is this: as long as the task is clearly defined it is easy for anyone to know when they are done. Focus on proper task definition and your staff will have a much easier time knowing what they have to do, and executing it. And you’ll have a better idea of where your projects are at.

Development is a very task oriented profession. Everything can be broken down into small requirements or tasks that need to be finished to get meet the overall goal. In some projects you might have hundreds of different steps to complete before you are done, and keeping track of these can be critical to success.

Different people have their own ways of doing this. Some just write it down on a sheet of paper, and strike off what’s been done. This works fine until you lose that piece of paper. Then you’re just screwed.

Others employ the use of some software that tracks tasks, who’s assigned to what and what is done. This option is much safer, and probably more reliable.

I’ve personally seen systems at both ends of the spectrum in use, and they’ve worked well enough. The big problem really comes when there is no system in place to track progression, or a system is only used part of the time. The end result with this is additional features that are unnecessary, or features that are missed.

Consistent, reliable task tracking that anyone in the team can access is not only important, but very helpful for each team member so that they know what needs to be done and what they should be doing. It’s helpful for management, because it allows them to get a better idea of how far along a project is, and if it’s on track to be finished on time. It’s much easier to manage and fix a problem early on because you’ve been made aware of it, rather than at the end when everything is falling apart.

“If debugging is the process of removing bugs, then programming must be the process of putting them in.”
-Edsger Dijkstra

Testing is arguably the most important step in any software project and also one of the most neglected steps. In most cases, testing is missed because clients don’t realize the importance of it and aren’t willing to pay for, or take the time to have the developers test properly.

In a perfect world, code would be thoroughly tested before it ever goes into the wild, but this just isn’t possible. Here are a few tips and tricks on testing so your product will never be released without even a little bit of testing.

White Box vs Black Box Testing

White Box testing uses an internal perspective of the system to design test cases based on internal structure. It requires programming skills to identify all paths through the software. Black box testing on the other hand takes an external perspective of the test object to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid input and determines the correct output.

White Box testing in my opinion is a lot easier as a developer because you understand the internal structure and you can create the tests as your write it. Black Box testing generally needs to be done by a third party who doesn’t know how the structure works (makes it easier to test). This testing can basically be created before the program is even written (as long as it’s designed).

Regression Testing

Regression Testing is the process of finding bugs in existing functionality that weren’t there before. All programmers, even the best in the world, add bugs into their software. The problem is that sometimes these new bugs can affect things that are already in place (and that you’ve already tested). Unless you have regression testing, these bugs won’t be found until your customers complain.

As I write my software, I’ll create tests for each method / class / etc… and then when I add in new functionality I go over the previous tests to make sure everything works the way its supposed too. This way I don’t get little surprises when I roll everything into production.

Get a “User” to Test

You can do all the testing you want but most of the time you’ll miss something small. Having a “User” (someone that would actually use your software) test your product can help find bugs that you wouldn’t have thought to check. There have been numerous occasions where I’ve had a friend test something I’ve written and found bugs that I didn’t know existed. It helps having extra minds thinking about testing.

Thoughts on Testing

Testing is extremely important. Your name is going to be on the software you release so even if the Customer doesn’t want it you should still test. You don’t want to give yourself a bad name as a developer.

We’ve now looked at Getting the Requirements, The Design Phase, and Start Coding of Creating Software. Stay tuned for the final installment.

A difficult, yet obvious, lesson to learn is that you need to know what you’re doing before you do it. Many developers just dive into a project without the proper planning or without fully understanding what it is that they need to get accomplished.

You might get a feeling of productivity because you’ve started coding, but what does it get you? What have you actually started to code? Chances are it’s not exactly what is required, and that means you’ve wasted your time. No matter how you cut it, wasting time is not productive.

Get the requirements

If you’re going to know what you need to do, get the requirements. Hopefully the document that you get has been approved by the client, so that they know what they are getting as well.

As a developer, you need to know these requirements inside and out before you start coding. If you don’t you run the risk of coding conflicting features, or making architectural mistakes that will have to be undone down the road, wasting more time.

Plan it out

Take the time to plan out what you’re going to do to meet the requirements. Put thought into each requirement so you’ll know how every component of your application will work together. Make diagrams, notes or whatever else helps you map out what you’re going to do.

Taking the time to plan an application well will save time coding. A well designed and well planned application will also be easier to change. The application will be leaner, more organized and far less frustrating than if it were an application a developer just jumped into and started coding without planning.

Get at it

Once you’ve got your plan, double check it against the requirements. People make mistakes, and mistakes waste time, so take the time to remove them. Once you’re sure you have what you need, and you know what you’re going to do, do it.

If you’re the kind of person that just jumps in without planning, try this a couple times and see how it improves the flow of your project. It might take a bit of time to learn how to plan well, but it’s a step, and it will help.

I don’t know about you but I personally work a lot better when I’m listening to music. I don’t know what it is but I can concentrate a lot easier and work a lot quicker when I’m listneing to my favourite tunes. The problem with most devevelopment jobs is that, unless you work from home, you’re constantly around co-workers and it would be rude to blast your music.

That is why it’s important to invest in a decent pair of headphones. Here are a few things you should look for when picking out your headphones:

• Comfortable Ear Pads

Because you’re going to be wearing these headphones for long periods of time, you’re going to want something that fits comfortably on your head. Now, if you prefer in-ear buds than you don’t need to worry about this.

Its always a good idea to try on the headphones before you buy them. That way you get an idea of what they’ll feel like and whether or not you’ll be able to wear them for hours upon hours.

• Long Cord

If your computer is tucked away from your desk like mine is, you’re going to want a fairly long cord. Most headphones come with at least a meter long cord and you can always buy extensions if its not long enoguh. You don’t want to have an overly long cord though because it can get in the way and get annoying very quick.

• Noise-Cancelling

Noice-cancelling headphones are great and the prices are coming down a lot, but they may not be right for your workplace. If you constantly have co-workers talking to you, having noise-cancelling headphones can be rude because you won’t hear them talk. I would advise not getting a pair because you won’t be able to hear people around you.

Here are a few tips on being polite while wearing your headphones:

1. Only wear the headphones over one ear
2. Play your music at a comfortable level to yourself and your co-workers
3. Always take off your headphones when a co-worker talks to you

Those are just a few tips on buying and wearing headphones at work, but what are your thoughts? Do you wear headphones at work? If you do, what kind do you have? Feel free to drop us a line down below in our comment section

I’ve met, worked with or interviewed many “senior” developers, and it saddens me to say it, but most of them haven’t improved since the day they left school.

Time in the industry doesn’t make you any better at what you do, and it surely doesn’t make you worthy of the senior title.

1. Skill

   Obviously any developer with the senior title should be very skilled at what they do. Not only should they know the ins and outs of their primary language, but they should have a good repertoire or secondary languages that they are fluent in.

   Aside from skill with their language, they should posses a solid understanding of computer science theory, debugging techniques and application design. Different jobs/languages also require extra skills. For example, a Sr. Flash Developer should have a solid understanding of all the different types of math required to build complex animations.

   Bottom line – your senior developer should be able to build anything you need them to. And it should be built well.

2. Initiative

   A senior developer should be taking initiative and changing things for the better around their place of work. They should be able to notice inferior tools and build something to replace it. They should notice when others have a weak point in their skill sets and try to train them up.

3. Leadership

   A senior developer should be willing to take responsibility for the work of a larger group of programmers, after all, the senior developer is taking initiative to make sure all the people he/she is working with have the skills and knowledge to do their tasks well.

4. Willingness

   You need to be willing to do the dirty work. A senior developer is not “above” doing any sort of work. They are always willing to do a task related to their job, to train someone new, or let a less experienced developer take a more challenging and fun project so that they can improve their skills.

5. Devotion and Passion

   Above all, passion for your work and a devotion to development itself will make the most noticeable difference. Someone with passion for development will be doing all they can to get better at it, broaden their skill sets and encourage the others that they work with to do the same.

   Passion is the characteristic I look for most in any potential hire, regardless of level, as I believe it is what truly makes the difference and sets an average developer apart from one who has the potential to be great.

Have other things that you think add to what really makes a Sr. Developer? Leave a comment and let us know. Disagree with our list, or a part of it? Let us know that too.

As a final note to those junior or intermediate level developers who think they have all these skills and are looking to become a senior level developer, just be patient and keep improving upon the things mentioned here. Most places only look for years of experience when “promoting” someone to a senior level.

Having a good manager can make the difference between an amazing work experience and a horrible one. At work, you can tell the developers that have a good manager from the ones that don’t based purely on how well they work and how happy they are.

As a manager, making your developers happy and comfortable can increase their productivity and make a better work experience for everyone. Here are 10 tips to becoming a great manager:

1. Know Your Developers

If you’re going to be a good manager you need to know the people who work for you. Getting to know your developers can be as simple as talking with them. Instead of bringing your lunch every day, go out to lunch with them and chat. Generally people talk about things they’re interested in so you’ll get an idea of what your developers like.

2. Have Good Communication Skills

You need to have good communication skills to be a good manager. You could be the most brilliant and perfect person for the position but if you can’t communicate your thoughts and directions, you won’t make it as a manager (or at least a great manager). There are plenty of bad managers that I’ve worked with and their biggest problem is they don’t know how to communicate with their staff.

3. Protect Your Developers

One thing that will make your co-workers and developers like you is to protect them from stupid people. Where I work, theres a certain team of people that no one likes because their requests are always extremely stupid. Whenever the other team does something that could potentially get us in trouble because of its stupidity, our manager will go up and talk to their manager and straighten things out. Protect the people that work underneath you and they’ll be more willing to do their best for you.

4. Actively Manage

Actively managing is the process of knowing what your developers are doing, and managing while not intruding and trying to enforce your way of doing things. You need to trust that they’re competent enough to do their jobs and you need to focus on managing them instead of managing what they’re doing. This one can be really hard if you’re a control freak.

5. Properly Reward Your Developers

Realize hard work and also realize what your employees like for rewards. If one of your developers especially likes a certain task, reward them with the ability to do that. These rewards don’t need to have monetary value, they can be as simple as allowing them to work on a different project that they like.

6. Give Your Developers The Tools They Need

It astounds me when I see a developer working with only one screen. If you’re going to be spending $50k+ a year, why not spend a few extra dollars to get the equipment that they need to do their job properly. Dual monitors, ergonomic keyboards and proper chairs will help the developers be more productive. Spend the money on your team to give them what they need.



Home  

---