How do I go from being able to write code to being a good developer?

Question

I'm frustrated by the lack of concrete explanations on how to go from being able to script (bash, awk) and write simple applications (c, php, python) to designing and developing larger, more complicated software. It seems that on one side there are programming language books and on the other side there are the software engineering/project management books designed for teams of programmers.

I've read plenty of both. I've read the XP/Agile classics and have a decent theoretical understanding of the software development process. I like to read other people's code and can follow it fairly well. But when I have an idea for a project or want to go from "here's the problem/need" to "here's the solution", my mind draws a blank and I don't know where to begin.

Do I just hack it out? Are there any structured workflows for individual developers that don't work in teams or for a big software house? I really don't have any desire to get a PMP or work for a software company. I'm just looking for an effective, efficient, practical workflow.

Answer 1

In my opinion, you become a good developer by having experience and working with multiple ways of doing things. You've stated that you have a problem going from "here's my idea" to "here's my solution". That's something more towards software development methodologies as well as being an experienced developer.

Using a software development methodology is more than "just hacking out code", and these methodologies provide structured workflows. There Agile family provides good structure for smaller development teams (or individuals) that you can follow to help you get from the "idea" phase to the "finished product" phase.

There's a few things that I've learned over the years from others and through working on various projects, such as:

• Make everything testable, this will make your life much much easier;
• You cannot expect to have a perfect design and be able to design enterprise applications/the next biggest game title/insert more here, without having experience in doing so;
• It is difficult to design good software if you have not had experience doing so and learned from others;
• You will never have a perfect design the first time, even as an experienced developer - things change and therefore; your design might too;
• Write things down: Writing/drawing/whiteboarding/painting/whatever it is you feel comfortable with, it makes life easier if you have things written down. Such as GUI designs, class diagrams, etc. In my experience, just going to "hack something together" has the potential to fail catastrophically;
• Don't reinvent the wheel, you shouldn't have to. If you're trying to implement your own HashMap then you're probably doing something wrong. Research things, and think before you write code.

Hope some of that helps.

Answer 2

Well, in my opinion, as in any profession, to be a good professional all what it takes -- besides theoretical formation -- is experience.

As a doctor cannot be good with only the classes taken in med school, or a lawyer cannot know all the political side of being an attourney with only its degree, being a good developer needs experience and time.

Experience doesn't come by reading third party code. If you get a med student, he/she would be able to point out a lot of procedures, deseases, medicines etc., but the actual application of these things (when to apply one procedure, what desease to diagnose etc.) only comes with supervision and experience.

Since you don't want to work for a large company (or any company for that matter), I suggest you start by developing small applications, one step at a time. Developing software by yourself takes a lot of time, belive me.

Other thing that I suggest to you to become a good software developer/engineer, is to contribute to open source software. A lot of guys have make a good amount of money (and experience, btw) by helping develop open source software and giving consultations afterwards. They have made a name for themselves with their contributions to open source.

Anyway, I think there isn't a shortcut to gaining experience, and it must be pursued with discipline and patience.

Answer 3

You can start by enhancing other people's code. Take some project you've got and add a feature to it. You'll have to decide what the feature is going to do, and how it should do it. Working within the framework of the existing code, design your solution.

And don't be afraid to hack stuff out. A lot of new development is done by refining (or preferably rewriting) quick-and-dirty prototypes. Go ahead and use every worst practice and antipattern in the book, just crank out something that does what you want. Then, go back and design it properly. Usually, I find myself thinking "You know, a better way to do this would be..." while I'm hard-coding some configuration parameters in my 800-line three-procedure monstrosity.

I know it's currently out of vogue, but the techniques of structured analysis really helped me get a handle on software design. Play around with making a few bubble charts and DFDs to get a feel for decomposing problems and designing different parts of a system to work together.

Answer 4

As others have said, experience comes from writing code. But you should also have someone else review your code if possible. A more experienced programmer can point out problems in your code and show you better ways of doing things. Contributing to an open-source project will give you a chance to do both.

Answer 5

For me, it helps to break down a larger piece of software into smaller chunks. And then break those chunks into even smaller parts and so on. Every software program is a collection of small pieces of logic.

Consider a blog, for example. You want to be able to create and edit posts that others can read. Right away you can split the project into admin and public sections. At minimum, the admin will require admin users, a login page, and a section for managing the blog. The section for managing the blog can be broken down into a CRUD (Create, Read, Update, Delete) interface. Creating a new blog post will require a check to make sure the admin user has the right privileges, a form, form validation, and the ability to save to the database. And so on.

The more that you break a problem or a feature down, the more manageable it becomes. It's divide and conquer. Once you've been able to map out your software like this, you can take a look at how different pieces of it interact with each other. Where might you repeat code? What can be abstracted? This should be an iterative process both as you plan and as you write the code itself.

I would recommend figuring out what your minimum feature set is to begin with and implementing that before adding other pieces to it. You'll want to code defensively so that future changes won't be too difficult, but at the same time, you don't want to implement half-features that may never get completed. It's a difficult line to walk between staying flexible and being willing to ruthlessly kill your darlings, to borrow a literary reference. Getting good at that particular balancing act only comes from experience.

And that's what it comes down to, as the other answers have mentioned: experience. The only way to get it is to just start. Don't worry so much about making it perfect from the outset. First make the code work, then make it beautiful, then make it fast.

Also, unlike this paragraph, don't tack security on at the end as an afterthought. You should have an idea about ways your software could be compromised, but as a start, never trust any user input.

Answer 6

I know you say you don't want to work for a software company, but that's a good place to get the experience many of the other answers talk about. And whether or not you want to work on big projects, exposure to other peoples' work and work styles are good things to have.

You can't try out Pair Programming by yourself, for example. And if you're paired with someone smarter than you, you get the added benefit of earning better practices from them while getting experience in that methodology.

BTW, I've made it my practice to try to work with groups where I feel I'm below the average in experience, skill, and the like. It raises my game tremendously. It's much harder to do that alone or where you're the "experienced" guy.

Answer 7

What you're looking for is problem solving skills. I've noticed that it is assumed that the developer can already do this, which is silly. Luckily, problem solving is a general skill, used in math, research, everyday life and so on.

Primarily, you should end up following the scientific method, with some frills.

1. You have a problem (use tools and techniques to help define this)
2. You hypothesize a solution (patterns and experience help)
3. Test hypothesis (you might not even have code here)
4. Repeat steps 2 and 3 until hypothesis holds. You now have a theory (working program to solve problem)
5. Develop an experiment to stress theory, looking for holes (test cases!)
6. If test cases hold, you have a solution! Otherwise, rinse and repeat

Notice that this is rather high level. Each step typically involves several substeps, such as determining what the problem actually is. As an example, look at solving word problems in math. You collect facts (a tool), and determine what is actually wanted. Then, you examine your facts, attempting to map them to the solution.

This ends up becoming sub problems of the primary problem. So, follow the steps again. We need an intermediate item to get the final result, so it becomes our new problem. This decomposes the problem down into small, easily understood, sections. As each piece is solved, the solution is pieced together.