Some Background
I have worked on several development teams over the years, and while I understand the reluctance to try new and exciting things on the part of management, I have still never gotten over this reluctance in young developers.
I should preface this by saying that I am not bashing younger developers, I am just sometimes disheartened to see that sometimes they aren’t as obsessed with it as I am. Maybe I am just too obsessed, and I take this all too seriously. Then again, it’s what I do for a living.
If there is a new technology or idea that will save me even five minutes a day, I am totally willing to learn it and adopt it until it deprecates.
So, here are some things that I have found lacking in the arsenal of a good deal of younger developers I have worked with:
The List
They don’t know more than one language
When I suggest that a problem might be tackled much more effectively using another approach (another language), it becomes quickly apparent that the developer doesn’t know any other languages, and while they might be a little interested in looking at another language, they are in no way serious about learning anything new.
Many times, they will make fun of other languages, and poopoo the stereotypical programmer of that language (or poopoo very important language concepts!). This is very unfortunate.
As a developer, you really should expand your horizons into other languages. Seeing how other languages tackle problems encountered in programming and understanding why those problems exist is monumentally important in developing the mind of a programmer.
They Don’t Know a Web Framework
Web frameworks are incredibly productive tools. There are lots of problems in trying to impose state on a stateless protocol. There are lots of novel approaches to mapping data models to databases.
The biggest reason I hear for not working with a framework is that they already have a pack of scripts they wrote, or worse yet, their own framework that they use.
There are some VERY smart people out there working on the problem. The ability to look at their code and their methods for solving the problem is very much worth the price of admission (free!). I you are in this boat, I would really suggest you take a look at a web framework. Try a small project in it, and see what you think.
One of the things that worries me about this is that these people usually have an employers who (even though indirectly) is paying them to reinvent the wheel every project.
They Don’t Use Version Management Tools
I have worked on teams where everyone worked on live code. I will get into why this is a HORRIBLE idea in a minute, but when there are three or four people working on the source code, you really need to have a version control system in place.
The biggest reasons cited for bypassing source code management are drive space and conflict management. In all reality, a source code project is tiny. It doesn’t take much space on each developer’s system at all. It’s most likely a negligible amount of space. If you are really worried about managing conflicts in your code, you are absolutely in danger of having problems with a team of developers working on live code.
Editing Live Code
This is probably the scariest thing I have ever seen, and I have seen it a few times. Here’s what it looks like: A production codebase sits on a server. Multiple instances of that application run on that same server. As changes are required to the code, the production codebase is edited directly.
Well, if there is one thing I have learned is that a great deal of the time, code I write doesn’t work on the first iteration. I write it, test it, and see if anything breaks. A lot of times, it breaks. Working on live code, if you break anything, all your clients’ code gets broken too. All their visitors are subject to your errors.
If anything happens to the system it’s running on, or any other hiccup happens, the whole system is in jeopardy. Words can’t express what a terrible idea this is.
They are Slaves to the Mouse
Maybe it’s because I learned all this stuff in the beginning with emacs. Maybe it’s because I have always learned the keyboard shortcuts for every app as soon as I started to learn it. I can just work MUCH faster with the keyboard. It seems to take up a bunch of extra time every time I have to fumble with the keyboard.
Maybe it’s because I am getting old that I can’t stand to watch someone pressing mouse buttons for every task that happens when developing and application. Whether it’s uploading code, compiling, or anything else. You really can move around much quicker by learning the keyboard shortcuts.
This also applies to the command line. There are lots of tasks in development that are just much faster when using the command line. Sure, there are lots of gui tools for pretty much everything, but there is an inherent cost in time for using those tools.
Unfamiliarity with Linux and Server Tools
When you develop a web application, chances are very strong that you will be using a slew of tools that you can run on your own development machine. These include programming languages, web servers, database servers, and the like. Believe it or not, it is much simpler to go bananas on your own machine, forking the codebase and testing out your ideas in a sandbox than it is to edit live code on the server.
If you want to be really efficient, you should take a look at starting up a development environment on your development machine.
In Closing
I really hope I haven’t offended anyone. That was not my intention. I think my intention was really to point out some very dangerous or inefficient practices that I see almost daily. To document them in the hopes that if your company or project is using some of these practices, you might think about changing them.
If you need any help or guidance, let me know.
developers, development, programming
Some Weaknesses I Have Found on Younger Development Teams
Some Background
I have worked on several development teams over the years, and while I understand the reluctance to try new and exciting things on the part of management, I have still never gotten over this reluctance in young developers.
I should preface this by saying that I am not bashing younger developers, I am just sometimes disheartened to see that sometimes they aren’t as obsessed with it as I am. Maybe I am just too obsessed, and I take this all too seriously. Then again, it’s what I do for a living.
If there is a new technology or idea that will save me even five minutes a day, I am totally willing to learn it and adopt it until it deprecates.
So, here are some things that I have found lacking in the arsenal of a good deal of younger developers I have worked with:
The List
They don’t know more than one language
When I suggest that a problem might be tackled much more effectively using another approach (another language), it becomes quickly apparent that the developer doesn’t know any other languages, and while they might be a little interested in looking at another language, they are in no way serious about learning anything new.
Many times, they will make fun of other languages, and poopoo the stereotypical programmer of that language (or poopoo very important language concepts!). This is very unfortunate.
As a developer, you really should expand your horizons into other languages. Seeing how other languages tackle problems encountered in programming and understanding why those problems exist is monumentally important in developing the mind of a programmer.
They Don’t Know a Web Framework
Web frameworks are incredibly productive tools. There are lots of problems in trying to impose state on a stateless protocol. There are lots of novel approaches to mapping data models to databases.
The biggest reason I hear for not working with a framework is that they already have a pack of scripts they wrote, or worse yet, their own framework that they use.
There are some VERY smart people out there working on the problem. The ability to look at their code and their methods for solving the problem is very much worth the price of admission (free!). I you are in this boat, I would really suggest you take a look at a web framework. Try a small project in it, and see what you think.
One of the things that worries me about this is that these people usually have an employers who (even though indirectly) is paying them to reinvent the wheel every project.
They Don’t Use Version Management Tools
I have worked on teams where everyone worked on live code. I will get into why this is a HORRIBLE idea in a minute, but when there are three or four people working on the source code, you really need to have a version control system in place.
The biggest reasons cited for bypassing source code management are drive space and conflict management. In all reality, a source code project is tiny. It doesn’t take much space on each developer’s system at all. It’s most likely a negligible amount of space. If you are really worried about managing conflicts in your code, you are absolutely in danger of having problems with a team of developers working on live code.
Editing Live Code
This is probably the scariest thing I have ever seen, and I have seen it a few times. Here’s what it looks like: A production codebase sits on a server. Multiple instances of that application run on that same server. As changes are required to the code, the production codebase is edited directly.
Well, if there is one thing I have learned is that a great deal of the time, code I write doesn’t work on the first iteration. I write it, test it, and see if anything breaks. A lot of times, it breaks. Working on live code, if you break anything, all your clients’ code gets broken too. All their visitors are subject to your errors.
If anything happens to the system it’s running on, or any other hiccup happens, the whole system is in jeopardy. Words can’t express what a terrible idea this is.
They are Slaves to the Mouse
Maybe it’s because I learned all this stuff in the beginning with emacs. Maybe it’s because I have always learned the keyboard shortcuts for every app as soon as I started to learn it. I can just work MUCH faster with the keyboard. It seems to take up a bunch of extra time every time I have to fumble with the keyboard.
Maybe it’s because I am getting old that I can’t stand to watch someone pressing mouse buttons for every task that happens when developing and application. Whether it’s uploading code, compiling, or anything else. You really can move around much quicker by learning the keyboard shortcuts.
This also applies to the command line. There are lots of tasks in development that are just much faster when using the command line. Sure, there are lots of gui tools for pretty much everything, but there is an inherent cost in time for using those tools.
Unfamiliarity with Linux and Server Tools
When you develop a web application, chances are very strong that you will be using a slew of tools that you can run on your own development machine. These include programming languages, web servers, database servers, and the like. Believe it or not, it is much simpler to go bananas on your own machine, forking the codebase and testing out your ideas in a sandbox than it is to edit live code on the server.
If you want to be really efficient, you should take a look at starting up a development environment on your development machine.
In Closing
I really hope I haven’t offended anyone. That was not my intention. I think my intention was really to point out some very dangerous or inefficient practices that I see almost daily. To document them in the hopes that if your company or project is using some of these practices, you might think about changing them.
If you need any help or guidance, let me know.
From → commentary, development, productivity