Getting started in the field of software development is difficult.
No doubt, if you are just starting out as a programmer, you have already experienced how difficult it can be to get a job without having much or any experience.
If you’ve been a software developer for any amount of time, you’ve probably experienced how difficult it can be to rise up the ranks in this highly competitive industry.
I’ve talked to many developers just starting out who are frustrated because they don’t know where they should be devoting their energies to best advance their careers and secure their futures.
There are so many options. So many technologies you could learn. So many paths you could take. Which is the right one?
Thinking the right way from the start
I’ll give some concrete advice in a little bit, but before any of that advice is useful, it is important to make sure you are thinking about your career in the right way.
It is really important to think about your career as a business. A business you own which employs you. Thinking this way will help you make the right objective decisions about what you should be doing with your time and how and when you should invest money in your career.
Too many software developers think about their career in terms of their current job or the job they seek to obtain—that kind of thinking is short sighted.
Have you ever noticed how it is easier to advise someone else on a decision than to make that same decision for yourself? The reason is because when you advise someone else, you are able to be objective and not let fear and other emotions influence your advice.
By thinking of yourself as a business, you’ll be able to create that same kind of separation and objectiveness which will lead you to better decisions.
Actually start a business
In fact, why not go the extra step and start a business right from the start?
It is difficult to get experience without having experience. Most software development jobs require you to already have experience.
So, how do new software developers or developers with limited experience actually get experience?
Often, you get a lucky break and perhaps you come into an organization in a QA position or other role and eventually work your way up to developer.
That is the long way.
Here is the short way.
Just start your own business from the get go and employ yourself. It isn’t hard to start a business. You don’t even have to file any paperwork to start out. You can just do business as yourself in most places.
But what about work? I need to actually make some money.
Ah, but the point of this starting out business is not to actually make money, but to gain you experience. You can keep your current job and you can run this business on the side. You just need some projects to work on so that you can put some real experience on your resume.
It is pretty unlikely that a prospective employer is going to ask how much money your business made last year, (even if they do, you don’t have to tell them.) So, don’t worry about making money. If you are able to get some paid jobs, great, but there is no reason you can’t do jobs for clients for free in order to gain experience.
Create a website for a friend or family member’s business. Talk to local businesses and ask them if they’d like you to develop an application for them for free or very low cost. It doesn’t matter where you get the business from, the point is to get something on your resume that is real work you did—then it isn’t lying. You don’t want to lie on your resume.
Develop some mobile applications
Here is another great thing that your business can do that will not only get you some experience to put on your resume, but will also possibly generate you some extra income and give you something to show at a job interview.
I often recommend that developers just starting out build mobile applications, because mobile applications can be built by a single person and are a great way not only to learn how to build an application from end to end, but to create solid proof of your ability to write code.
One of the biggest fears that companies have when hiring developers is whether or not that developer can actually produce anything. You can completely alleviate that fear if you can show the source code for an application you created yourself, and if you have it in a mobile app store and people are actually using it, even better.
If you are looking to find out where to get started with mobile application development, I have two Pluralsight courses on the subject: Introduction to Android and Beginning iOS 7 Development. You can check those out or find a good book on the subject.
Here are a couple I’d recommend:
Besides gaining experience to put on a resume, building your own mobile application will help give you confidence in your ability to create real working code and it will help you to develop well rounded skills in software development.
Sure, it may be a bit difficult to get started and there is a decent amount to learn about mobile development, but it is a good investment regardless, because mobile devices aren’t going away anytime soon and the demand for developers that can develop for mobile platforms is only likely to increase over time.
Plan your career
I talk about the idea of marketing yourself as a software developer quite often, because it is something I truly believe can help software developers to get better jobs and earn higher incomes.
Much of this advice comes down to actually planning out your career rather than just looking for the next job.
You want to set yourself up early on in a position where you are building a brand and reputation for yourself that will benefit you later in your career.
A great way to do this is to create your own blog. Don’t wait to do this until later on. I wish I would have started this blog 5 years or more earlier in my career. Every developer with a successful blog that I have talked to has said the same thing.
Don’t just create the blog, use it. Strive to write an article each week. Even if you don’t have anything interesting to say, do it. After a few years, you’ll be a better writer, have a nice history of your thoughts and be all the better off for it.
I’m not going to go into all the details of marketing yourself in this post, but if you are interested, I do have a course that covers everything you need to know about marketing yourself as a software developer.
The key point here is to plan your career and think for the long term. Create a blog, establish a brand, do other things that will benefit you years down the road, but start doing them now.
Find the right friends (mentors)
I’d advise you to make friends with experienced software developers and utilize the wisdom they can impart on you.
It can be difficult to make friends if you come off as needy. It is unlikely that if you ask someone to be your mentor, they will accept. Being someone’s mentor doesn’t really offer much to the person doing the mentoring.
The key is to have something to offer in return so that you are providing value as well.
Here are a few ideas to make some friends in the industry:
- Offer to buy lunch. This is a good opportunity to have a conversation with someone who you otherwise might not be able to. Who doesn’t like a free lunch?
- Start commenting on software developer’s blogs that you admire. You’ll eventually gain their attention if you provide useful, insightful comments.
- Find something to trade. Do you have some knowledge in some other area that someone might be interested in? Can you trade your knowledge of fitness or diet in exchange for information about software development? The best relationships offer value to both parties.
- Go to user groups. There are many user groups all over the world that you can become a part of. If you are a regular, you will meet other regulars and build good friendships.
Read the right books
One of the best ways to really get ahead of the curve is to read the right books. Reading the right software development books can help you to understand concepts that take years to discover on your own and give you the benefits of the collective experience of many successful software developers.
Here is my personal list of books that I’d recommend all software developers start out with.
Code Complete – A classic book about the structure of code. This will make you a much better programmer and help you write clear code.
Clean Code – A great book by Bob Martin that really distills down some key concepts about writing good code. A must read book.
Design Patterns – Read through this book several times and learn these patterns. It may take some time to grasp them all, but they will show up again and again in your career.
Programming Pearls – Work through the problems in this book. They are hard, but the effort is worth it.
Agile Software Development, Principles, Patterns, and Practices – Another Bob Martin book, but also a must read.
Good luck. I hope you found this advice useful. Starting out is hard, but if you are smart about it and deliberate, you can boost yourself several years ahead of others in your same position.
If you found this post useful, don’t forget to sign up here to get more content like this delivered to your inbox.
What would you think if you were interested in buying some new product you heard about, but when you went to the company that created the product’s website you found it wasn’t there, because they didn’t have a website?
Today, we expect pretty much every reputable company to have a functioning website.
But, many developers—web developers included—don’t have any kind of online presence of their own.
Sure, you may have social networking accounts, like Facebook and Twitter, but do you have a website that you own which you can point people to as your castle on the web?
The importance of having a home base for marketing yourself
I’ve talked before about how important it is to market yourself as a software developer, but I’ve never really gone into the details of how.
I’ll be creating a series of posts dealing with the subject of marketing yourself over the next few months, starting with this post on what I believe is the cornerstone to any success software developer’s self promotion strategy, building a blog.
As you’ll see in this series, it is actually pretty easy to get started creating a blog—probably simpler than you may think. But, before we get into the details, let’s take a moment to talk about why it is so important to have a home base on the web, especially for a software developer.
It really begins with how you view yourself as a software developer and your software development career. Many, if not most, developers view themselves as a software developer who does a job. For the most part, there is nothing really wrong with this view, but it is not the best way to think about what you do.
Instead, you are better off thinking of yourself as a business. Sure, it may be a one man or one woman business, but the truth of the matter is that you are providing a service to a client, even if that client happens to be your boss.
When you think of yourself and your career as a business that you are building, you suddenly are no longer exempt from needing a web presence. Just like we might think it would be pretty bizarre for a company that we do business with to not have a website, your clients and customers will think it is bizarre if you don’t have one—especially if you are a programmer that specializes in web development.
For most developers, your blog will be your main presence, or your home base on the web. Your blog is a chance to tell the world about what you are doing and show what you can do, and to completely control the message and image you present. This is an extremely powerful concept, because it allows you to shape the way potential and present customers and clients see you and can really increase your exposure.
This really is the key to marketing yourself online.
But, I don’t have anything interesting to talk about
Hogwash. That excuse is just no good. Everyone has something interesting to talk about.
This is an excuse I hear pretty often, and it seems like a good one—until you really sit down and think about it.
As a beginner, it can seem like you are not good enough; like what you have to say isn’t important; like there are so many other people that have much more valuable advice and opinions. But, the truth is different people at different levels in their knowledge of a subject, or with different kinds of combination of subjects they have knowledge about, can reach and provide value to different sets of people.
Let me break that down a bit.
What I mean to say is that just because you are learning C++ and there are C++ gurus out there with 30 years of experience and more knowledge about C++ then you may ever have, doesn’t mean that you don’t have something valuable to offer.
Sure, Herb Sutter might know more about C++ than you, and other C++ experts may gain valuable information from his blog, but can he reach the C++ beginner, like you, that is just starting out as well as you can? Probably not.
The truth is sometimes an amateur can reach other amateurs better than a professional can.
The truth is sometimes a woman can reach other females better than a man can.
The truth is sometimes a younger 20 something person can reach other 20 something people better than a programming dinosaur can or vice versa.
Chances are if you find it interesting, someone else does to. So, stop using that excuse. You can create a blog and it can provide value. You just have to be willing to put in the work.
I’m not looking to advance my career or sell something
Again, I have to say this excuse is a bit short-sighted. You might not be looking for another job right now, or to move up the ladder, but chances are, at some time in the future, you will be.
The biggest mistake I see developers make with career advancement is waiting until they need a job to start doing things like networking or blogging.
This is a bad idea, because it reeks of desperation and building up momentum, be it with blogging, networking, or something else, requires time.
Ideally, you want to start your blog and start using it to market yourself and your skills, before you need to. Then, if the well ever dries up, you’ll have plenty of prospects.
The same goes with selling something. You may think that you’ll never have something to sell, but if you ever write a book or decide to sell some consulting hours, having a blog can bring you clients and prospects instead of you having to go out and search for them.
Ok, so hopefully, I’ve convinced you to at least consider creating a blog that will serve as your home base on the web– which will be your primary tool for marketing yourself online.
I can’t tell you how many opportunities have come to me from having this blog that I would have never expected.
But, you may be wondering how to get started with creating your blog. If you are like me, you probably want to know what options you have and how to pick the best one.
In my next post, I’ll talk about the 3 main options for creating a blog, give you the one I personally recommend, and give you one really important piece of advice that you won’t want to ignore.
Just check back next week, or you can sign up here to get updates, so I can let you now when the next post goes live or when something else interesting is happening at Simple Programmer.
And if you can’t wait till next week, take a look at this book: Technical Blogging: Turn Your Expertise into a Remarkable Online Presence. (It is from a fellow developer who gives some tips on creating a successful blog.) I really enjoyed this book and found some great tips in it.
Oh, and if you are super excited about the idea of learning to market yourself as a software developer to boost your career, I am taking limited pre-sales for my new complete course and package “How To Market Yourself as a Software Developer.” I’ll announce more about this later, when it is ready for an official launch, but if you are quick, you can get in early and help shape the course.
What slows down the development of software?
Think about this question for a bit. Why is it that as most software evolves it gets harder and harder to add features and improve its structure?
Why is it that tasks that would have at one point been simple are now difficult and complex?
Why is it that teams that should be doing better over time seem to get worse?
Don’t feel bad if you don’t have an immediate answer to those questions. Most software practitioners don’t. They are hard questions after all.
If we knew all the answers, we wouldn’t really have these problems to begin with.
Regardless though, you’ll find many managers, business owners, customers and even software developers themselves looking for the answers to these questions, but often looking in the wrong place.
Process is almost always the first to be blamed. It stands to reason that a degradation of process or problems with the software development process are slowing things down.
Often there is some merit to this proposition, but I’ve found that it is often not the root cause. If your team is not sitting idle and the work that is important is being prioritized, chances are your process is not slowing you down.
Now don’t get me wrong here. I am not saying that these are the only two important aspects to judge a software development process, but I am saying that if generally your team is working hard on important stuff most of the time, you can’t magically improve process to the point of increasing productivity to any considerable order of magnitude. (In most cases.)
Often questions are asked like:
- Should we pair program or not pair program?
- Should we be using Scrum instead of Kanban?
- Should we be changing the way we define a backlog?
- Should we use t-shirt sizes or story points or make all backlogs the same size?
- Do we need more developers or more business analysts?
- Do we need to organize the team differently?
Now these are all great questions that every software project should constantly evaluate and ask themselves, but I’ve found over and over again that there is often a bigger problem staring us in the face that often gets ignored.
Let’s do a little experiment.
Forget about process. Forget about Scrum and backlogs and story points and everything else for a moment.
You are a developer. You have a task to implement some feature in the code base. No one else is around, there is no process, you just need to get this work done.
It might help to think about a feature you recently implemented or one that you are working on now. The important thing with this experiment is that I want to take away all the other “stuff” that isn’t related directly to designing and implementing that feature in the code base.
You will likely come to one of these conclusions:
1. The feature is easy to implement, you can do it quickly and know where to go and what to modify.
Good! That means you don’t really have a problem.
2. It is unclear what to do. You aren’t sure exactly what you are supposed to implement and how it fits into the way the system will be used.
In this case, you may actually have somewhat of a process problem. Your work needs to be more clearly defined before you begin on it. It may be that you just need to ask more questions. It may be that half baked ideas are ending up in your pipeline and someone needs to do a bit more thinking and legwork, before asking a developer to work on them.
3. Its hard to change the code. You’ve got to really dig into multiple areas and ask many questions about how things are working or are intended to work before you can make any changes.
This is the most likely case. Actually usually a combination of 2 and 3. And they both share a common problem—the code and system do not have a design or have departed from that design.
I find time and time again with most software systems experiencing a slow down in feature development turnaround that the problem is the code itself and the system has lost touch with its original design.
You only find this problem in successful companies though, because…
Sometimes you need to run with your shoelaces untied
I’ve consulted for several startups that eventually failed. There was one thing in common with those startups and many other startups in general—they had a well maintained and cared for codebase.
I’ve seen the best designs and best code in failed startups.
This seems a bit contradictory, I know, but let me explain.
The problem is that often these startups with pristine and well maintained code don’t make it to market fast enough. They are basically making sure their shoes laces are nicely tied as they stroll down the block carefully judging each step before it is taken.
What happens is they have the best designed and most maintainable product, but it either doesn’t get out there fast enough and the competition comes in with some VB6 app that two caffeine fueled not-really-programmers-but-I-learned-a-bit-of-code developers wrote overnight or they don’t actually build what the customer wants, because they don’t iterate quick enough.
Now am I saying that you need to write crap code with no design and ship it or you will fail?
Am I saying that you can’t start a company with good software development practices and a clean well maintainable codebase and succeed?
No, but what I am saying is that a majority of companies that are successful are the ones that put the focus on customers and getting the product out there first and software second.
In other words if you look at 10 successful companies over 5 years old and look at their codebase, 9 of them might have some pretty crappy or non-existent architecture and a system that departed pretty far from the original design.
Didn’t you say something about pulling up your pants?
Ok, so where am I driving at with all this?
Time for an analogy.
So these companies that are winning and surviving past year 5, they are usually running. They are running fast, but in the process of running their shoelaces come untied.
They might not even notice the shoelaces are untied until the first few times they step on one and trip. Regardless they keep running. And to some degree, this is good, this is what makes them succeed when some of their failed competitors do take the time to tie their shoelaces, but those competitors end up getting far behind in the race.
The problem comes pretty close to after that 5 year mark, when they want to take things to the next level. All this time they have been running with those shoelaces untied and they have learned to do this kind of wobble run where they occasionally trip on a shoe lace, but they try to keep their legs far enough apart to not actually step on a shoelace.
It slows them down a bit, but they are still running. Still adding those features fast and furious.
After some time though, their pants start to fall down. They don’t really have time to stop running and pull up those pants, so as they are running those pants slip further down.
Now they are really running funny. At this point they are putting forth the effort of running, but the shoelaces and pants are just too much, they are moving quite slow. An old woman with ankle weights power walks past them, but they can’t stop now to tie the shoelaces and pull up those pants, because they have to make up for the time they lost earlier when the pants first fell down.
At this point they start looking for ways to fix the problem without slowing down and pulling up the pants. At this point they try running different ways. They try skipping. Someone gets the idea that they need more legs.
I think you get the idea.
What they really need to do at this point though is…
Stop running, tie your shoes and pull up your pants!
Hopefully you’ve figured out that this analogy is what happens to a mature system’s code base and overall architecture.
Over time when you are running so fast, your system ends up getting its shoelaces undone, which slows you down a little. Soon, your system’s pants start to fall down and then you really start to slow down.
It gets worse and worse until you are moving so slow you are actually moving backwards.
Unfortunately, I don’t have a magic answer. If you’ve gotten the artificial speed boost you can gain from neglecting overall system design and architecture, you have to pay the piper and redesign that system and refactor it back into an architecture.
This might be a complete rewrite, it might be a concerted effort to get things back on track. But, regardless it is going to require you to stop running. (Have you ever tried to tie your shoelaces while running?)
Don’t feel bad, you didn’t do anything wrong. You survived where others who were too careful failed. Just don’t ignore the fact that your pants are at your ankles and you are tripping over every step, do something about it!
Now that I am not a consultant anymore, I can finally write about this topic.
This is one of those likely to piss people off topics, but this is something I feel every consultant should know.
So, what am I talking about?
Basically, I am saying if you are working as a contractor, or other type of consultant, and there is a middle-man between you and the direct client, you need to know what you are being billed out at.
Why does it matter?
The main reason is that you need to be able to know how to negotiate your rate. Over the course of your career in software development, negotiating your rate can be worth hundreds of thousands of dollars.
That is kind of a big deal!
It just makes good business sense. If you are working as a consultant, you are, to some degree, running your own business. A good businessperson knows what everyone is making on the deal. It isn’t an unreasonable thing.
Let’s consider an example. Have you ever bought a car? If you have, did you walk into the dealership and pay the sticker price?
When I go to buy a car, I ask for one thing. The dealer’s invoice. Then after he gives me the fake one, I ask for the real one. I want to know what their cut on the deal is. The dealer deserves a fair markup for the service he is providing, but as a customer and businessperson, I also deserve to get a decent price.
Taking that example a little further, what if you went in to buy a car and the sticker price was $25,000. Then the dealer and you negotiated and he came down to $23,000. Now, let’s suppose you found out that he got the car from the factory at $20,000. The seems fairly reasonable. 3k is a decent amount to make on a car, but the dealer is going to have some overhead and other costs associated with being in business.
Now, imagine in that same scenario the dealer bought the car for $10,000. If you found out that piece of information, you might be pretty outraged. You might consider why you need the dealer. Is he providing 13k of value to the transaction? Should you get your own dealer’s license?
In any kind of business deal, everyone should have a good idea of who is adding value and at what cost.
I’ve been in the real estate business, the software development business, and a few other industries, and one thing I have learned is that the best business deals have the most transparency. Nothing will ruin a deal or make a sour relationship more than missing disclosures.
In business everyone has to make money, but everyone wants to feel like they are getting a fair shake. When I am selling something, I will gladly state my cost. When I am buying something I expect someone to be able to tell me what their cost is.
If you are a consultant you need to be making sure you are in a good deal, otherwise you are in risk of under pricing yourself. You need to push for transparency. If it is a good deal, it should be a good deal for everyone.
They won’t tell me my bill rate
Did you ask? How did you approach negotiations?
One important thing I have found is not to talk about hourly rates. Instead, you should be talking about margins and markups. As a consultant doing 1099 work through my corporation, I always state that I allow for a 15% markup on my services.
In my opinion, this is more than reasonable. And yes, I am flexible to a degree, but the point is: from the beginning I am talking about markups and margins, not about hourly rates. Make sure you start the conversation there. You are a professional and a business person, act like one. If you don’t want to be treated like a commodity don’t act like a commodity.
You may not be able to get the exact numbers, but you should be able to get a general idea of what the bill rate is. There is no reason why any professional should be billed at 2-3 times what they are being paid. The middle-man does not provide the value that deserves that kind of markup, yet it happens all the time. Don’t be a victim.
Don’t be afraid to do some research yourself. It is fine to say “I know that you are probably billing the client around $100/hr… “ Don’t be afraid to fish a little.
One word of caution here. A middle-man does deserve to make some money. If they found the job and found you, and they are handling the payroll, that service has value. You cannot expect them to make nothing, just make sure it is a fair amount in regards to the service they are providing.