The Five "Continuous" Aspects Every Developer Should Focus On This Year
These five types should be "continuously" on your mind as a developer. Today, I cover two technical aspects and three behaviors a developer should focus on building personally.
Disclosure:
I get commissions for purchases made through links in this post.
As a developer moves through their career, there are a number of skills and characteristics that they should pay particular attention to whether they work in a freelance or a corporate environment.
Since we are a little bit past the middle of the year, I would've rather made this a New Year's post, but we can move past that and do a reflection of what we can do to improve for the remainder of the year.
This post is meant to show the number of "continuous" types or skills every developer should strive for as a professional.
Continuous Integration
If you haven't setup automated builds at all, I would highly recommend you download the version control system of your choice and try to set it up locally in a Virtual Machine to test it out.
Continuous Integration is the process of checking in code and having another server build the project, and optionally, run other tasks such as running all of your unit tests to confirm that your code behaves properly.
There is no reason why you couldn't download Jenkins, Hudson, TFS, TeamCity...or whatever your flavor is and start using it.
Why? There are a number of companies that are in desperate need of Continuous Integration servers. Personally, I set up Jenkins on my server at home and it was one of the best things I could've done.
It feels so good to compile a project with the push of a button and see an artifact (the result of a build) in a directory.
Continuous Delivery/Deployment
Do you know what feels better than a one-click continuous integration build? A one-click deploy! Once you finish your continuous integration, start focusing on your continuous deployment.
Continuous Deployment goes hand-in-hand with the Continuous Integration and is what I consider a key part to a DevOps operation. One example of your deployment mechanism could have the following build formats:
- DEV_Project1
- DEV_Project2
- QA_Project1 (You could replace QA with UA or STAGING)
- QA_Project2
- PROD_Project1
- PROD_Project2
The way I've encountered deployments is that DEV and QA/UA/STAGING would be automatically deployed after a build passed, but PROD would not be automatically deployed.
Production should be a manual process. If something happens where a database change wasn't deployed, but the product (whether a website or fat-client) was deployed, there could be some disastrous consequences.
At the beginning, it may be hard to create the build and time-consuming, but it's worth it in the long run.
Once you say it, it feels sooooo good. Say it with me..."One-Click Deploys".
Awwww yeah!
Continuous Etiquette
While the previous two are more technical, the remaining three are more of a professional nature.
With that said, I've met a lot of professionals who I don't consider "professionals" at all. They don't know how to conduct business in a professional manner and lack business etiquette.
When you leave the house and head to work (actually, some don't), everyone you encounter on your travels should be given the same courtesy and understanding they would show you in return.
You may think that this particular point is trivial, but you would be surprised how many "professionals" out there in the real world don't follow the "Golden Rule." They are constantly out for themselves.
The good news is that karma is a bitch and it comes around often.
Of all of the unprofessional people I've encountered, I've never had to deal with them again. If I did, it was a short encounter or discussion and that was the last time I've seen them.
Always be courteous, friendly, and helpful. This will place you at the top of your game and everyone will want to work with you.
But keep in mind, it's a continuous effort.
Continuous Interaction
Nice segue.
Now that you've mastered etiquette, start applying those well-mannered skills.
As a developer, you can stay cooped up in a cubicle forever without interacting with someone (just ask Milton).
You can exercise your socializing skills at:
- The Water Cooler
Maybe your friend's neighbor is looking for a website to build his new business? - Conferences
You would not believe how many opportunities abound at developer conferences. - Local User Groups
You could easily ask the head of the local user group to speak about a particular topic and that gets you in front of a lot of developers. - Networking "After Work" Gatherings
A great opportunity to create personal business cards to demonstrate your portfolio to potential customers (By the way, I use MOO Business Cards, MiniCards and Postcards (affiliate link) and I LOVE THEM!) - Be Social on Social
Even though virtual, use Twitter as a conversation piece to create virtual relationships. You never know where it could take you. Trust me.
I'm pretty sure you want to be a known developer like Linus Torvalds, rich like Bill Gates, and have a personality like Sir Richard Branson, but you can't do it from your cubicle, Milton!
You need to get out there and stretch your wings and show what you can do. So be social and continuously interact.
Continuous Improvement
In order to stretch your wings, you need to master your craft by learning more and build even more projects and applications. You accomplish that by always learning about how to become a better coder.
Over time, you will be able to see the difference between an interface and an abstract class (don't laugh...some people I've interviewed don't know the difference).
Your experience will be considered valuable. The only one who will be able to see that is you.
Sites like Udemy.com (affiliate link), Lynda.com(affiliate link), and PluralSight.com (affiliate link) are who I consider to be the kings of learning. For a small nominal fee (usually monthly), you can take an unlimited number of courses to learn as much as you want.
And I hear your brain will grow twice it's size (just kidding).
My point is that you should always be improving your skills. Even though you're out of school, it doesn't mean you stop learning. Remember that!
One of my philosophies is to always have at least two skills mastered. If a language or technology tanks and takes your one skill with it, you have the other skill to fall back on until you can recover while learning that second skill.
Conclusion
Overall, these continuous types should always be on your mind. I am constantly thinking about how to improve my continuous integration and deployments for projects.
The first two are meant to make your life easier while the remaining three allow you to become a better person and developer.
Life is way too short to do any less.
Did I miss a "continuous" type? Post your comments below.