My background is electrical engineering, DSP to be more precise. The company I currently work for does a lot of diverse projects, mostly building analog hardware. Being somewhat closer to computers than everybody else around here I'm often the one writing code for both embedded devices (which I'm perfectly fine with) and Windows or Linux OS. It is the latter that is foreign territory to me.

I can code, and I know a few languages (C/C++, Java, some VB.NET), but I only used them for algorithm simulations in signal and image processing, neural networks, and other similar applications. For me programming has been a computational tool more than anything else. However, I get more and more projects where I have to write proper full-fledged software, and I don't really know how to do it, because I never had to do it, and I was never really interested enough. I have myself seen quite a few engineers who got converted into coders to a certain degree because of job demands, and most of them weren't that great at what they did. I'm sure many people have encountered the same.

If I were to learn writing proper software with good user interface, good internal architecture and so on, how do I do it? We don't have anyone at work who could tell me what's good practice and what isn't. Given that I can write code in the rawest sense of the word, what else is there to know about writing good software and how I do I get there on my own?

  • If you gave told us the language that you are using, we maybe able to give you more in depth answers. Then again, that would negate the point of a generic answer. – Sardathrion - Reinstate Monica Oct 10 '11 at 15:02
  • 2
    Without formal training or direct work experience with a mentor then doing things the Right Way™ will not be realistic. You are learning. There is a reason why computer science and engineering branches off from electrical engineering. A sane company will hire software engineers to write application interfaces, application drivers and even firmware because they want quality and want it to be done right and have it be maintainable. I would explain to your boss that what you are doing is a little beyond your realm of expertise and that these tasks should be best left to a software engineer. – maple_shaft Oct 10 '11 at 15:56
  • 4
    ... I want to add too that I don't think your situation is as "involuntary" as you state in the title. You said yourself that your peers don't even know how to use a computer, yet you are required to also be a software engineer involuntarily? That hardly seems fair. I commend your ability to write passable software and your desire to learn and do things the right way, however there is no shame in admitting to your boss and yourself that some things are not in your capabilities. If they are serious about placing you in this role, ask them to spend on training for you. – maple_shaft Oct 10 '11 at 16:00
  • @maple_shaft I agree with most things you're saying; however, I never said that my peers don't how how to use a computer. None of them is a software engineer who could couch me, but they're all very much computer proficient. I have no problem with having to do the coding, I like learning new things, and I don't really have a problem with doing it. – Phonon Oct 10 '11 at 16:10
  • 6
    @Phonon Great, that is a good attitude, but make sure that your company buys you books, training courses, and gives you time to learn if they want you to play that role. That is all I am saying. So many companies will try to cheat you by convincing you that it is your responsibility to purchase these things for yourself. – maple_shaft Oct 10 '11 at 16:25

There are a few books that will help you a lot. I suggest to have always next to you Code Complete. It is an invaluable reference. In a previous company where I worked this was also the book we gave every junior programmers after being hired.

The Pragmatic Programmer is also a really useful resource and it is pretty short, but I suggest you read it after Code Complete.

These books will get you started, then code, code, code and code more...but know when to stop, your software will never be perfect.


My company does this all the time...and it drives me nuts.

"I'm a software developer, how do I become a EE?"

Well, I think the answer is fairly obvious. It takes a lot of time and hard work. And of course, the right learning materials. The Engineering background helps, at my university the CS and engineering schools were in the same building with a lot of overlap. The algorithms and math foundations are there.

A mistake I see most newcomers make is to bite off way more than they can chew. Learning materials across UI, architectures, quality code...that's a lot of ground. Something that takes years really and is often done by teams of different experts at software companies.

Not to say you can't be pretty decent on your own, if you put in the time. Just recognize the magnitude of the materials so you don't overwhelm yourself and either A. Quit or B. Build major technical debt into your apps by taking major shortcuts in your learning process.

Because of all this, there's no "catch-all" become an awesome dev with this book out there. I recommend you start by picking up a well rated book on your most used language and also participating in the Stack community especially for code reviews.

Try Amazon.com, they have good book reviews.


Books: The main thing is to read (good) books on your language of choice. Once you know your language of choice, you can get "More Effective X" or "Y best Practices" and so on. I find cookbooks to be very good at bridging gaps you may have. So, I guess that is at least three books you need to get. One thing: do exercises and code kata to improve your understanding of the language. Of course, you need a good xUnit pattern.

Algorithms are particularity important and you should pick a book that details them -- again, in your language of choice. Design Patterns and Anti-Patterns are worth while knowing about in any languages whatsoever.

Bottom line: it takes time. Do not rush.

  • +1, but always be aware, that there is only one rule has no exceptions: all rules have exceptions. – Jan Hudec Oct 10 '11 at 15:40
  • @JanHudec: Which one(s) did you have in mind here? – Sardathrion - Reinstate Monica Oct 10 '11 at 15:45

You suck in coding. Yes.

But - this doesn't mean you can't deliver software, that makes people happy ;)

Be humble. Write the "business" logic, that you need. Use library code for everything else. Do not attempt to write fundamental algorithms (like array sorting), do not use any "fancy tricks", stick to some draconian code-convention.

Use good IDE. This is essential, as it will help you to format your code and track typos / simple mistakes.

Read books like "Code Complete" and "Pragmatic Programmer", try to force yourself and learn OOP (its simple, and will help you keep your code more maintainable).

Use SVN, commit often, - so you will be able to revert your changes (when you will ruin something).

Find somebody, who is a real programmer, with academic background, if possible. So you will be able to talk with him sharing your newbie problems, and getting enlightening answers.

And, of course, the most important thing is to also keep coding, coding, coding.

p.s.: if you are able to write C++ code that works, and you write neural networks(!) - then your brain is well suited for programming ;) Good luck!


There are good answers here.

A big spin in your favor is the simple fact that you want to know.

Much of software engineering (which you should take with healthy skepticism, of course) is about how to do it in ways you won't regret later. One example is the use of a source code version control system. Another is dividing the code into files so it's easier to work on it piecemeal. Another is to be a stickler about orderliness - code formatting and naming conventions. The exact conventions don't matter as much as being consistent about it.

That way, when you come back to the code in a year or more, you won't think "Who made this mess?" You will be able to find things and change them without too much risk of breakage.**

A good way to get started is to find various example programs and work through them. Then you can adapt them to your needs.

** One of my biggest headaches is trying to work with code written by people who did not think formatting or naming mattered.


While there are lots and lots of good resources on how to do and don't do things, in the end most important thing is seeing a lot of code and working with it and see how easy or complicated it is to maintain for yourself.

A good way to learn is to have somebody experienced to do the initial design and than review your code and show you useful techniques as you have use for them. So if you by any chance manage to persuade your bosses to hire at least one software engineer with experience in leading (small) software projects and designing software to lead the projects, I think it would be the best option.

If you can't get anybody to couch you, there is these days strong open-source movement. Perhaps you use some open source tools in your work, so try to fix bugs in them or add simple features that you have use for and discuss how to do those things with respective community. It is a unseful hands-on learning exercise to learn how to apply any general rules you'll find in the books on actual practical problems.


One thing I would really recommend for learning quality coding and architecture concerns would be the teachings of "Uncle Bob" (Robert Martin). He has some $1 videos that are nicely bite-sized, if perhaps overly whimsical, as well as some good books.

Not the answer you're looking for? Browse other questions tagged or ask your own question.