Programming beyond programming

I pride myself on being a good software developer and being a software developer involves coding but to be a good developer you have to look at software development more broadly.


  

Clear goals

This one seems like the most obvious be you wouldn’t believe how many people start out on a software project without knowing where they are going or without fully understanding what other people want or are working on. It’s ok to work on in sprints and let your uses show you where your projects should go but in those development prints you should know exactly what you want.
Understanding (business) needs

Besides scope creep I think this is the biggest way that development projects fail. Even if you’ve discussed the project some things get lost in the cracks. It’s important to be able to get inside your customer’s head and anticipate what they really need or what they don’t know to ask for. Sometimes this means putting your business hat on and looking at the problems the company has.

Being reliable / not committing to what you can’t do

This is really a combination of a couple of ideas. You should be able to estimate how long a project will take. While this isn’t an exact science you should try to improve your estimates. A good idea to improve is to estimate everything software related that you do including personal projects and college projects. Over time your estimates will become more realistic.
Another thing is learning how to say no, but in a reasonable way. I’m not talking about being lazy but if you have too much on your plate you should communicate that or if estimates are unrealistic you should say something. Maybe people can be added, maybe you can get more time or maybe features can be delayed.
As a general rule it’s better always acknowledge problems, maybe there is something that went wrong, maybe you made a mistake but problems nearly always get worse as deadlines approach, usually dealing with them early is a lot easier.
Being organized and keeping your data tidy / being nice to the people coming after

This means version control, fighting fragmentation and having a system or conventions for where things go. Be predictable and clear about how you do things. It saves confusion and doesn’t waist mental energy.
Project management

Most developers aren’t project managers in the formal sense but at the same time a lot of what they have to do is project management. The problem is they don’t think of it as such and don’t have the training.
A developer should be able to read a gant chart and identify the critical path as well as estimate time.
Dealing with stakeholders (like customers)

Soft skills mater too. I think compassion for what customers need is lacking. Besides just the specs of the project customers often need need you to be a guide about how a project works, what to expect and what is realistic. It often helps to remind them that your goals are the same and to stay in contact to avoid going off in different directions and everyone gets what they want.
Your own mental energy

 Programming is metal and requires mental energy. Therefor a good software developer is one that has a lot of mental energy. This means exercising and eating right, sleeping well and not expending mental energy at work on things like are not important. I think of each decision you make as having a small cost. Wether its to use an switch or and if statement or where you put that note on your desk or where you stored that file. This is part or why it’s so important to be organised. Weather it’s GTD or Agile or it’s keeping you desk clear try to have a system. If you can automate automate. If you can’t automate have a system. If you have to decide on things try to do it just once and make a personal policy for how to do it every time from now on.
Constant up skilling

I once talked to a recruiter that thought it was a bad thing I had a number of programming languages on my CV. She thought it meant I wasn’t focused. I don’t see things that way. Technology is always changing and a programmer needs to always be up skilling. And even looking sideways at other technology in other segments. I learned a bit of assembly to get a better idea of how memory management works and how compilers work. I don’t see that as a lack of focus since that information helped my in other languages.
Remember the saying wasn’t “jack of all trades, master of none”. It was originally “jack of all trades, master of few”. Have core set of skills (languages / technologies) but don’t be afraid to look at other things to see what ideas are being used. You’d never know when a few years down the line an idea might be adopted into a new language.
Be flexible

This is related to the above. I’ve never lied about being an expert in something when I wasn’t but quite often in this industry you have to work on something you weren’t trained for. There is a knack for getting things done in that situation. I’ve learned C on the job, I’ve fixed a phone system after that phone companies engineer decided he didn’t feel like it, I’ve fixed python scripts onsite with no python experience.
I think this comes down to not being afraid to dabble.