What is needed for a self-taught developer to be able to move into senior-level and leadership positions?

Question

I'm a self-taught developer that currently has more than enough experience to hold up against my colleagues waving their degrees. Still, I feel that I'm lacking some important skills to advance into being a senior-level professional in a leading role, specifically in the engineering, planning and designing aspects of software.

I've touched the surface of UML, ERM/ERD, have experienced projects managed using waterfall and Scrum. I feel there is something missing, as every time I start on a new project, I don't know where to begin. Should I start diagramming and how? Should I start writing a document describing the project on a technical level first, or should I dive head first into writing the initial tests and code, or pseudo-code?

I would like to know what, in my case, would be the best way forward, to learn how I can tackle this problem in the future and get better at leading and starting a project. There is not much I don't know about my technical tools and languages, but when it gets abstract I'm in trouble.

Answer 1

Take a course in Project Management. It seems that's where you're getting stuck. This is not unusual, large projects can be hard to manage at first. And if you don't have a degree, that's fine. Project Management is not usually taught as a standard part of a CS curriculum, it's usually taught as a separate diploma / certification course.

Also, does the company you work at have a standard template or formal process for starting new projects? I've worked with that before, where someone has already defined the starting documents for any project. It can be helpful, even for developers.

Answer 2

A degree doesn't help anyone answer the questions you raised. They are common questions.

You can stop worrying about your lack of a degree now. It doesn't much matter.

Also, non of these topics are "abstract". They're very concrete.

Should I start diagramming and how?

Some folks like to start with pictures. Use case diagrams are a good idea. Class diagrams can help clarify the static structures. Activity diagrams can help clarify the processing.

should I start writing [a] ... document describing the project on a technical level first,

Some folks like to have a "big picture" overview so they know where all the details go.

Other folks create an outline for the final documentation and fill it in as they go.

should I dive head first into writing the first tests and code or pseudo-code?

You can't write test cases without actors and use cases. So you have to start with the people who use the software (the actors) and the use cases. Once you have a pretty good idea what the use cases are, you need some kind of rough, initial, high-level design. Once you have some design (and possibly some initial code), you can then write test cases. Once you have test cases, you can finish the code.

Answer 3

... every time I start on a new project I don't know where to begin.

Welcome to the force, kid.

A few things you might find useful:

• Use cases let you build a description of how the system looks from the outside, which gives you some sharp edges to hang your general plan on ("they mostly care about data entry and reporting; we'll need three, subsystems for entering, storing, and reporting the data")
• User stories let you refine that description into concrete requirements, which can drive actual software design ("they want to be able to select a customer and then see the dates and total amounts of all their orders, so we'll need a component which can associate customers with orders, and another which can compute order totals")
• CRC cards let you work out and capture the structure of the system on paper (well, card) in a flexible and mildly fun way ("the OrderFinder can talk to the OrderSummariser - but should it pass order numbers, or complete order objects?")
• The idea of a minimum viable product can help focus on which features are really important, and therefore how big your plan has to be before you can start developing ("they absolutely need to be able to see order totals for each customer, but sorting the orders by value is a nice-to-have that can wait until later")

More generally, i suspect that there are a lot of ideas from the iterative and agile worlds that can help, because a major focus there is on working out what to do right now, and then getting it done.

Answer 4

One of the standard texts in the field is Pressman's Software Engineering. I've opened it up only for interviews since I graduated. Another scintillating gem in the academic field is the IEEE SWEBOK. I have a negative opinion of the goodness of college software engineering/project management courses. I'm sure some college somewhere has a good course set (Maybe Stanford? MIT?). I just haven't heard of any yet.

Answer 5

What to learn for a pure practical developer to get better?

That's easy: "learn a totally non-practical system", either a very academic language (Haskell, Erlang, Prolog are the usual suspects, there are others), or a different framework with an emphasis on whatever aspect you find "nice but non-practical".

It will make you better. guaranteed.

Answer 6

My suggestion would be to consider studying design patterns, architecture and see what patterns can you find in how some problems are solved. At the same time, figure out if you are more of a top-down or bottom-up person when it comes to fleshing out a design. Do you like to start with a high level overview where things are vague and then have to be pieced together or would you rather start with identifying various pieces and then stitch them together? Each approach has its merits and drawbacks but which works better for you is something only you can know as you consider it feels to try each approach with some problems.

---

While I did learn of those heuristics in university, I'm sure there are many people that didn't go to college or university that found, "Hey, I like using this approach," and may call it something else. The key here is to find what works for you and exploit it with tons of practice. Consider doing some little side project of making an app or web form for something and see how easily can you map out what you want and repeat this a few times to see what answers come indirectly.

Answer 7

It's sad, but ultimately it is always politics. Senior level and management positions are always political in nature, and to get to them you need to have the right connections. It is very sad, but true. You can probably easily identify people who got to their positions solely on politics alone at your organization.

Just because you are a good developer, that doesn't always make you a good fit for a leadership position. The skills that leadership needs that developers can get by without (in other words, the stuff you need to know) include conflict resolution, profit sense, and budgeting. Senior people need to also understand "good enough," which is something that goes against the common developer mentality of "always optimized to the fullest."