"Alone" programmer, what should I learn?

Question

I just have been hired by a company, not a software company, but, kinds of service company. We here get requests, develop them into services, forward these services to sales department, and then start new one...Here, we use no standard: design, code contract, test,... Everyone gets his job's requirements, does it, separately, then reports that his work is "done". Supervisor checks that the job works as expected. That's all. I'm totally on my own now.

I want to learn and apply some "standard" on my work, such as unit testing or domain-driven design, I just don't know how to choose standards that fit my situations best, and which one will needed when I switch to a more professional environment.

So, my question is, which skill I should learn, and how I can learn them? I'm working with .NET (C#, ASP.NET MVC,..), so answers that focus on this framework are much appreciated.

Thanks in advance.

Answer 1

Your focus is on switching to a more professional environment.

To figure out what you need to learn, take a look at the job advertisements that companies you would like to work at are posting. This will tell you what skills they are looking for and will let you focus your learning on what will get you into the jobs you want.

In general, it is better to learn principles (clean code, patterns, class/code structure and organization) than specifics, as the specifics change very quickly.

Answer 2

Unit testing and full-service testing

There's nothing quite like making a change, running a battery of tests on it, and having a certain level of confidence that your change didn't break something else.

Your confidence is only as good as your test coverage, so learning how to write good test cases is key -- code coverage, making sure that you test all the decision points in your code (not just lines of code, but follow each decision through every if, case, while, etc).

Nunit is probably a fine unit-testing tool to learn for .Net. (.Net is pretty foreign to me, but ?unit is a well-known testing design, so learning one framework should make transitioning to other frameworks less painful than learning the first one.)

You might want to start implementing Nunit tests for your own hobby projects first -- I'm guessing your employer doesn't have much flexibility for on-the-job-learning. But you'll have to gage that.

Source-code control

Keeping everything except throw-away code in source control is key to maintaining sanity. There's no reason for keeping four or five versions of a program's source in one directory, or wondering which pieces of code you've copied-pasted from a 'fixed' version to one you're trying to extend.

When you check in changes, try to check in just functionally-related changes at a time. You might need to revert changes later, and if a changeset actually includes two, three, or more unrelated fixes or features (or worse, both fixes and features) then picking specific pieces back out later can be very difficult. Also, try to write your commit messages as if someone else will read them. Someone else might. And you count as 'someone else' in six months time.

It's easy to reap big benefits from source control quickly, and it is easy to build extensively on it -- the Linux kernel community tries very hard to maintain an it always builds state with every commit, so that people can use tools such as git bisect to help find changes that broke specific features. If it doesn't compile, those tools are much less useful. But this can be something you strive for, you don't have to be perfect right away. Please promise me you won't use SourceSafe -- at least with piles of files in directories, you know where you stand. Git, Subversion, Mercurial, BitKeeper, Darcs, Arch, all are significantly better than SourceSafe.

In general

I'd also like to suggest developing a serious case of paranoia and skepticism. Assume your users are trying to break your software. Imagine them stuffing completely incorrect inputs into every input mechanism in your software, and figure out how to fail gracefully.

Answer 3

You need Practice Practice and more Practice to become a Best. i thing that you need to learn Starting from Fundamentals. Because starting from fundamentals give you all information about the specific technologies. If you started from A then when you go to Z you know much more then you start from middle and go to Z.

Answer 4

The other answers mentioned good points. But also learn Test Driven Development methodologies in general, and continuous integration (CruiseControl is one tool). These will help you when moving to a more professional environment.

Answer 5

Read below:

http://www.joelonsoftware.com/articles/fog0000000332.html

Answer 6

These are the things i would start with

Version Control like svn, or git, ...

automated build a build definition that works without manual steps is really important

UnitTesting to start implementing testing

a incident database to track bugs and requirements

if you have implemented all of the above start thinking about

code metrics like codecoverage of the unittests, qualitymetrics, ...

A continuus integrationsserver like hudson to generate nightly builds and testruns

more automated teststing like loadtests, regtressiontests, ...

Answer 7

Try to become lazy programmer.

1. Try to minimize writing same line of code repeatedly. Why not a function do my repeated task.
2. Try to create your own library functions which you can use in multiple projects.
3. Keep reviewing your code to find a better way.
4. Start from Structured oriented programming. When you find you have enough library functions start breaking them in classes and start switching into object oriented programming.
5. Try to use General exception handling in the starting and narrow your exception handling in every steps to get awareness of exception handling. Error logging as convenient
6. Try to find bugs in your code as you know what all things can happen in a code.
7. Read for new features added to new version of language.

Read books to make concept more and more clearer as programming on system dont clear concepts unless you take care of yourself why using this class or function what all this can do. What will happen if I do this in place of that.

http://stackoverflow.com/questions/1959295/i-cant-create-a-clear-picture-of-implementing-oops-concepts-though-i-understand

Answer 8

I'd start a source control server on a machine that wasn't my main desktop; it helps a lot to be able to rewind to a better place.

If any significant number of bugs came back, I'd create a bug tracking server, like Bugzilla, to be able to track what's broken/what needs to be fixed.

I'd buy and read the Pragmatic Programmer and also Code Complete.

And I'd plan, after one to three years, to find a more structured job, if it still appeals to you at that time.

Answer 9

Peer Reviews

I agree with most of the above, to I must say that Peer Reviews are the single most effective way of producing quality code. While unit testing and all rest is super for ensuring quality, there are several major benefits from peer reviews.

• First of all if you get hit by a bus, someone else understands your code.
• You are forced to write code other people understand and you are likely to write more comments.
• You can learn for others' mistakes.

A great sales-pitch for your boss is the part about you being hit by the bus. :) But, no in all reality this means that company will have better endurance, fewer bugs getting pushed to production and more knowledgeable developers.

It is simple to implement, does not cost a lot for the company and most research shows that in the end it actually saves the company a whole lot of doe.

The worst part is having your code critiqued, and you will often all fairness that is Rule #1 of being a good programmer.

I would greatly recommend the book Applied Software Project Management· It covers all the subjects mentioned above.

Best of luck!

Answer 10

The most important thing is requirements.

Make sure you get the request requirements accurately and what they mean (how to test them). Write down some tests for each requirement, and verify that those tests would be reasonable for the requirement. Half the time thy will say "no...its like .." and you just saved yourself a week of programming.

Keep track of what requirements you've done and which ones you haven't.

Make sure your software meets the requirements by reviewing before submitting.

Question, to make sure you've got the real requirements. Develop iteratively, so you can demo and verify that you are on track to meeting the requirments.

Everything else is just a means to this end. Testing, design etc. ... it's all for the purpose of writing software that meets the requirements.

Answer 11

Read www.ExtremeProgramming.org.

If you are alone you cannot do pair programming, but still you can start your morning with pencil and paper and write your goals for today that you will tick during the day when your code is written, tested and in source control. Be elastic in your agility, it is OK to test GUIs manually, but testing non interactive code really makes one more productive. You should create your system for backups, version control, unit tests, logging and defect tracking. I use a local git database in a DropBox folder in my most minimal environment.

Answer 12

Take the Joel Test. http://www.joelonsoftware.com/articles/fog0000000043.html Work your way through that list 1 by 1 until you have most or all of them checked. I did this when I started working for myself. It's very hard to "do it all at once" and the Joel Test gives you a bullet list which you can prioritize on your own and work through slowly.

Answer 13

Pretend you are working for a larger company, with a team of developers, and writing code that lots of other people will see. As many other people have suggested, use source control. If the company doesn't provide it, use your own. Build up libraries of things that you use all the time, and include them with every project (a utils library, a math library, whatever). Although it's a pain, it is important to document these libraries well, in case you forget. At the top of each of my code files, I include a header that has a date, original author, a description, and a rough revision log that outlines big features or changes. Then that way when I come back to it in a few months, it's a little easier to jump back in and remember basically what was going on. Pretend that lots of other people will be seeing your code, and write it accordingly.