Beginning Developer Advice: Getting Started

Home » Advice for New Developers » Beginning Developer Advice: Getting Started
Your Journey Starts Here on a blackboard

I am coaching a young guy at present who wants to be a developer and is just a first year in college (age 16/17). We meet up once a month or so. A few of the things we talk about might find its way into this blog.

The main thing I have said so far is to make a plan; he has two years at college, so the first year with me is going to be spent working on C# and desktop apps, the second year on web apps. That way he will have a broad understanding of software development and also may have found what he may like to take up as a career when he leaves college/university.

The main thing when you are starting is to want to do it and having a reading list. I hope I can help in this respect with the reading lists I am developing on this site.

A bit of general advice to new developers to set the scene for future posts:

  1. There are no shortcuts to being a good developer; you have put the time in, practice writing software and make mistakes along the way so you can learn from them.
  2. It is important to learn your chosen language and tools in good detail, so you know just what is possible and can learn to write concise code. I can judge how well somebody knows something by just looking at a few lines of code they write.
  3. Is C# or VB.NET the right language for you or should you go for the LAMP stack (PHP, MySQL, etc??). I can’t really answer that without my bias as a .NET developer. The only thing I will say is that I chose .NET over 10 years ago because I felt that I could write more concise, easy to maintain apps in a reasonably productive timescale, and I have never regretted this decision. All I suggest is you give it a try, its a rich language and toolset and in recent years with Azure, finally has a scalable architecture that suits applications with larger numbers of users.
  4. A tip I received when I was just starting, that I think is just as relevant today: always try to understand the business side. The end user is the reason why you are developing. Ok, you might be like Steve Jobs and not consult the end user because you think you know best, but you are still developing for the end user and you had better understand the problem you are trying to solve very well. Steve certainly did that. Although with software you are generally better off trying an Agile technique and getting feedback from your end users sooner rather than later, to help steer your ideas.
  5. Learn to name the elements of your code correctly. Usually this means giving everything a meaningful english name, no shortenings or notations, apart from Interfaces (which begin with I) and User Interface elements (which can have the object type appended, e.g. CustomerNameTextBox).
  6. Always understand the impact of any changes you would like to make. This means you have to read the code first to understand what it does, and is one of the reasons why its so important to write code that is readable to begin with.
  7. Do not try to optimise your code without measuring performance first; otherwise less than readable code can result for no real benefit.
  8. Always try to leave code in better condition than what you found it. However this is not a licence to change code without fully understanding the impact of your changes, or fully testing the new code. Usually I seriously consider improving code that I have to change at the time; other code gets carefully considered and may be noted for changing another day.
  9. Learn how to use a source control system, concepts and operational details. This is an important tool often overlooked.
  10. Its easy to get sidetracked when dealing with complex technical tasks like writing code. While you should sidetrack when learning (in order to learn something properly), its not good to sidetrack too much when writing production code. Here you should put the needs of the system first, not yourself. This is one of the reasons why Agile is good, because in working with your end user it helps keep you focussed on what they actually need.
  11. As well as learning to code, learn to read code. Pick open source projects on codeplex and read the source code to see how it works (do not go for examples produced by third party tool vendors as some of this code is very second rate and only serves the purpose of the tool vendor to show how clever they are).
  12. Given that there are a lot of things to learn, make time to learn something new every week, read a new book every month etc. Whatever it is if you reserve the time for it, you will look back and marvel at how far you have come. I do that even today after 30 years as a developer.

How to achieve the above? Some of this is down to skill and judgement that comes from experience, so start with your reading list and some example projects where you actually try to write code without looking automatically at the finished results in the book. Also much is certainly material for future posts on this blog.

About Phil

I have been working as a software developer since 1983. This blog could have been called "From Fortran 77, C and Cobol to C# in 20 (not so) easy years", but it doesn't sound quite right somehow. Besides I'm talking about what's happened since 2003, not before!

Leave a Reply

Your email address will not be published.


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">




Top Posts & Pages

Categories

Recent Posts

Recent Comments

Archives

Blogroll

  • Mike Cohn's Blog
  • Scott Hanselman's Blog
- mike@mountaingoatsoftware.com

When estimating in story points, teams should think in terms of ranges and rounding up. Here’s why. [...]

- mike@mountaingoatsoftware.com

Batman would make the perfect Scrum Master. Once he eliminates crime in Gotham City, I plan on offer [...]

- mike@mountaingoatsoftware.com

It can sometimes be a challenge to get people to attend and then participate in sprint reviews. Here [...]

- mike@mountaingoatsoftware.com

The standard “As a...I...so that…” user story template has stood the test of time. Here’s why each o [...]

- mike@mountaingoatsoftware.com

From helping teams understand the boundaries of self organization to creating safety around things l [...]

- Scott Hanselman

There's some interesting stuff quietly happening in the "Console App" world within op [...]

- Scott Hanselman

As I've mentioned lately, I'm quietly moving my Website from a physical machine to a numbe [...]

- Scott Hanselman

I'm quietly moving my Website from a physical machine to a number of Cloud Services hosted in A [...]

- Scott Hanselman

I'm doing a quiet backend migration/update to my family of sites. If I do it right, there will [...]

- Scott Hanselman

Technical Debt has a way of sneaking up on you. While my podcast site and the other 16ish sites I ru [...]

Meta