Looking for a job at a software company? Coding isn't everything.

[TimeBomb]

Hey all. So, fun fact: Even if you're a great coder, as a software programmer in an actual company, working with a team on a product, you have to be prepared to do a lot more than just code.

You must be registered to see links

really covers some of the key points that you may not be familiar with, yet you're going to need to know to be even remotely effective on an actual professional team, regardless of your skill level.

Cheers!

 

[sunnyboy]

I'm not looking for a job at a software company and have had no real education at a school in the field, and I have 8 out of 10 of those xD

 

[Negata]

Out of these I keep seeing probably lack of #1 Version Control as one of the most fatal flaws in people (students I guess) who'd otherwise make somewhat decent team members. The second most crippling absence of skill might be efficient usage of CLI tools and IDE's (#6). Watch someone working on their code for half an hour who lacks these and tell me you don't begin to die inside out of frustration.

The list seems kind of obvious and it's easy to forget these skills don't come for granted.

 

[שเ๒єtгเ๒є]

I'm a programmer who actually earns money by working as programmer in a company.
The article is right, but even that is not everything.

You also have to ...
- master OOP even without code (inheritance, associations, overloading, overriding, and so on ...)
- master UML diagrams
- know how to write (requirement) specification documents
- know how to test code (perhaps unit tests)
- write instruction documentations about your creations
- learn to comment your code so everybody who have never seen a line of your code can understand it fast
- learn to improve your code in efficient ways
- UNDERSTAND EVERYTHING, to avoid traps and problems, every problem you create will cost the company money, specially when the problem reaches the clients of your software product
- learn to help yourself, use web resources on any problems, because for (simple) problems you are old enough to Google, other people got problems, too

 

[Negata]

I'm a programmer who actually earns money by working as programmer in a company.

that's cool

I have to say I don't do diagrams or other documents for purposes of documentation but I sometimes draw with a co-worker so it's easier to be sure we talk about the same things. I wouldn't disagree they're good skills to have but I haven't had to apply them much.

I very rarely comment my code, either. The way I see it if code needs comments then it's poorly written. I did write one comment today, though. I wanted to leave an explanation why a certain function was run after a timeout instead of instantly and since it was to overcome a difficulty with a specific browser there is no good way to rewrite the code so that it'd be self-documenting on that issue. Then again this is in no way a rant against comments and I'm sure the the ability and habit of commenting your code well must come before the code itself starts to take readable enough form. So I guess learning when not to place comments and how to avoid need for comments altogether goes with that.

 

[Dave]

Nice link.

An other thing which is important is being able to actually communicate with other coders and the project manager. It is not a secret that many people in the IT sector have issues with being social and communicating in real life.

It's also important to be up to date with the technology you use for all of your projects, things get updated all the time and expanded with new features.

 

[שเ๒єtгเ๒є]

I have to say I don't do diagrams or other documents for purposes of documentation but I sometimes draw with a co-worker so it's easier to be sure we talk about the same things. I wouldn't disagree they're good skills to have but I haven't had to apply them much.

Diagrams take time, but sometimes there is no turn around for them. Currently I have to re program a software that will be replaced on almost all of our clients. Some things will change (like the OO model, configuration system - trying to get back from INIs and reaching XML - , and more). In this case it's very important, because the whole conversion of existing settings is so complicated, if we lose the overview it could get very expensive.

I very rarely comment my code, either. The way I see it if code needs comments then it's poorly written. I did write one comment today, though. I wanted to leave an explanation why a certain function was run after a timeout instead of instantly and since it was to overcome a difficulty with a specific browser there is no good way to rewrite the code so that it'd be self-documenting on that issue. Then again this is in no way a rant against comments and I'm sure the the ability and habit of commenting your code well must come before the code itself starts to take readable enough form. So I guess learning when not to place comments and how to avoid need for comments altogether goes with that.

At home, I almost never comment my code, too. Just trying to comment code I'm sure I will reuse again (DLLs) and when it's very complicated so I could lose the overview about it after some time. Mostly I know my code, nobody needs to read it.

In the company it runs the other way. The supervisors fear the moment you leave the company and leaving a bunch of un-commented code. New staff have to read it for weeks to finally get into work, maybe longer, depends on the projects.

The right approach would be to employ the new staff before the old go to have a fade time new people can learn from the old people. But they rather decide to spare money and force good documentations and comments on code. The safest would be to do both, because there are solutions that are very complicated, even with documentation and comments on code.

You are right there are often situations comments are not necessary. It's not the point to comment a declaration or every loop. On some projects though, many actions lack on sense (so need to be commented very strict) when just reading the code:
- clients with special wishes
- components that do not work like expected and need work-arounds
- stupid behaviors of the languages
- useless old shity code (that made sense just in past) you cannot simply remove because you don't know where it's used <- a common problem, specially on the communication on service endpoints, dare you remove or rename anything, tons of (third party) software will cry about it!!!

It's also important to be up to date with the technology you use for all of your projects, things get updated all the time and expanded with new features.

Yep, this job will never get boring, the brain stays fit by learning.

 

[Negata]

- clients with special wishes
- components that do not work like expected and need work-arounds
- stupid behaviors of the languages
- useless old shity code (that made sense just in past) you cannot simply remove because you don't know where it's used <- a common problem, specially on the communication on service endpoints, dare you remove or rename anything, tons of (third party) software will cry about it!!!

Yeah those are often solid reasons to use comments. Sometimes though you can take the preferred route of abstracting the stupidities away into a method call or a variable whose name alone documents what it stands for. A bonus in this approach is that while comments easily get outdated (just read a post on this a while ago), you need to make a conscious decision to write illogical code if you update semantics on such function without updating the name. I guess for novices browsing this thread I should give examples on this but I'll pass this time, I'm sure you know what I'm talking about.

It may depend a bit on the language you use, too. I think I might comment a lot more if I'm programming for example in C++ vs a more concise and expressive language like Ruby.

 

[שเ๒єtгเ๒є]

Yeah those are often solid reasons to use comments. Sometimes though you can take the preferred route of abstracting the stupidities away into a method call or a variable whose name alone documents what it stands for. A bonus in this approach is that while comments easily get outdated (just read a post on this a while ago), you need to make a conscious decision to write illogical code if you update semantics on such function without updating the name. I guess for novices browsing this thread I should give examples on this but I'll pass this time, I'm sure you know what I'm talking about.

Thats a good example of unnecessary comments and in most cases the function names are pretty fine. But I want to show a good example, where there is such no way to avoid this extra work:

		/// <summary>
		/// Attaches onclick-JavaScript to an element to make sure it cannot be clicked twice. 
		/// Works for submit behaviour-buttons as well as for simple buttons. 
		/// This is even supported by all types of validation groups. 
		/// </summary>
		/// <param name="button">Button to prevent twice clicks.</param>
		/// <param name="newTextAfterClick">Text that is put in the value tag of the button after click. Null to leave it as designed.</param>
		public static void PreventMultibleClicksEnable(Button button, string newTextAfterClick = null)
		{
			string newTextAfterClickArg = newTextAfterClick != null ? "this.value='" + button.Page.Server.HtmlEncode(newTextAfterClick) + "';" : "";
			button.Attributes.Add("onclick", (button.CausesValidation ? "if(typeof(Page_ClientValidate)=='function'){var v=Page_IsValid;var b=Page_BlockSubmit;if(Page_ClientValidate('" + button.ValidationGroup + "')==false){Page_IsValid=v;Page_BlockSubmit=b;return false}}" : "")
				+ newTextAfterClickArg + "this.disabled=true;" + button.Page.ClientScript.GetPostBackEventReference(button, String.Empty).ToString() + ";return true");
		}

I actually love this example, because the method is so small, but the action that is performed is huge. It will take an ASP.NET button server control and modify its JavaScript to disallow to click the button twice. It's a bit hacky, because you have to interfere into the ASP.NET process.

Visual Studio made it pretty cool to code, because of this:

This extremly helps us to keep up the motivation for commenting.

It may depend a bit on the language you use, too. I think I might comment a lot more if I'm programming for example in C++ vs a more concise and expressive language like Ruby.

Ofc it does, I fully agree with you.

 

[Negata]

Documenting a function's purpose, now that's never a bad idea. Something I guess I should do more, I'm not in the habit of doing it often but I do it when my judgement tells me it's important to document any possible side-effects or perhaps a return type or thrown exception when it might not be obvious.

Because you have documented the function's purpose and usage like that, this in turn must reduce need for bloaty comments in the other end wherever the function is called.

 

[Jolin88]

A skill that isn't taught at schools but should, is how to write maintainable code.
I think it's one of the most important aspects of code, no matter how correct your code is, if it's not maintainable you will get a lot of hate.
Instinctively a programmer would code towards an implementation, it's what you're taught at school and it seems obvious, but in a company you will quickly notice that it doesn't work that way. If you don't code towards an interface and try to keep things generic, future changes will make you rewrite more and more of your classes and it will become a big mess of conditionals upon conditionals and adding new features takes a lot of effort and can possibly cause side effects.

 

[.Yoss.]

"The first thing that happens to new hires is they get assigned to fix ticket #8347 in the bug tracking system." So they have experienced programmers who shovel it into people who can barely afford notepad and don't know what's going on. A++ comedy for the boss.

 

[Chris]

I very rarely comment my code, either. The way I see it if code needs comments then it's poorly written.

Gonna have to disagree with you there. I've had to deal firsthand with projects that are thousands of lines of code that are both commented and uncommented.

Sure, when you're writing it and familiar with it, comments aren't the most necessary (obviously because it's recent, and still fresh in your mind); but when you're re-visiting it a half year down the line when you've dealt with 5 other projects that are thousands of lines long, you won't be so acquainted with that one you worked on 6 months ago.

Commenting used to be something I never would think twice about, and I wouldn't have been caught dead going through and commenting a project once I was finished. That's why it's best to train yourself to comment as you write. The more you do it, the less of a burden it will seem to be.

For the sake of your sanity, and the sanity of other developers, please, please comment your code.

 

[TimeBomb]

Gonna have to disagree with you there. I've had to deal firsthand with projects that are thousands of lines of code that are both commented and uncommented.

Sure, when you're writing it and familiar with it, comments aren't the most necessary (obviously because it's recent, and still fresh in your mind); but when you're re-visiting it a half year down the line when you've dealt with 5 other projects that are thousands of lines long, you won't be so acquainted with that one you worked on 6 months ago.

Commenting used to be something I never would think twice about, and I wouldn't have been caught dead going through and commenting a project once I was finished. That's why it's best to train yourself to comment as you write. The more you do it, the less of a burden it will seem to be.

For the sake of your sanity, and the sanity of other developers, please, please comment your code.

I used to think this. But Negata's right. In most cases.

You should give

You must be registered to see links

a read. (And support him by

You must be registered to see links

.) Specifically Chapter 4, Comments.

 

[Chris]

I used to think this. But Negata's right. In most cases.

You should give

You must be registered to see links

a read. (And support him by

You must be registered to see links

.) Specifically Chapter 4, Comments.

That is true. I'm not saying there's no such thing as bad comments; but no comments at all is never a good thing in my book. Whether or not the code is written with readability, staring at a wall of code that you haven't seen in months [or ever] [strike]can be[/strike] is intimidating, and it's nice to have comments placed throughout [whether they're informative or explanatory].

 

[Negata]

That's why it's best to train yourself to comment as you write. The more you do it, the less of a burden it will seem to be.

For the sake of your sanity, and the sanity of other developers, please, please comment your code.

I guess if you don't know whether you should comment something it's better to be on the safe side and do so.

If you're with the impression my code is terrible on the eyes for lack of comments, good, I think my message got through. However please realize I don't omit commenting to avoid the burden, I do so in favor of readability which in turn usually makes the code easier to follow and thus to understand. I often stop to view a code block I just wrote and think to myself, this could use some clarification. The first attempt to solve it is always to rewrite the code itself, second comes commenting. Even then I may drop the comment if I consider it to be too much of a burden to the reader and the context seems clear enough - and surely sometimes moving the comment you thought of writing up to describe the bigger whole instead may be wiser.

We're on the same boat here, we all demand code that is easy (as possible) to understand. And hey I'm all for the "comment your god damn code or cry and comment it" motion. After all it's very rarely the case where code you read is too heavily commented.

 

[Chris]

I guess if you don't know whether you should comment something it's better to be on the safe side and do so.

If you're with the impression my code is terrible on the eyes for lack of comments, good, I think my message got through. However please realize I don't omit commenting to avoid the burden, I do so in favor of readability which in turn usually makes the code easier to follow and thus to understand. I often stop to view a code block I just wrote and think to myself, this could use some clarification. The first attempt to solve it is always to rewrite the code itself, second comes commenting. Even then I may drop the comment if I consider it to be too much of a burden to the reader and the context seems clear enough - and surely sometimes moving the comment you thought of writing up to describe the bigger whole instead may be wiser.

We're on the same boat here, we all demand code that is easy (as possible) to understand. And hey I'm all for the "comment your god damn code or cry and comment it" motion. After all it's very rarely the case where code you read is too heavily commented.

Honestly, yeah. We can go on about how too much commenting is a problem, but I have never run into code that had too much commenting. If only we could be so lucky. If anything, reading that will make me think twice about when I write my comments moving forward.

 

[Ron]

I've never been in a situation where I've thought "man, there are way too many comments here". Commenting a lot is never a bad thing, until you're on a deadline and you're overdoing comments and wasting too much time.

That being said, people need to summarize comments correctly. Comments are for short, brief reminders, not multiple paragraphs explaining a function in its entirety. You should know what a function does by looking at the code or function names. Comments are for quick notes saying why something should be increased by two instead of increased by one, or explaining things that aren't immediately clear after reading the code.

 

[Negata]

I have to disagree there, the best kind of comments might be those explaining a function's purpose, input and output in their entirety so that you don't even have to read the source. But of course the take depends on your role and how familiar you're with the project already. The kind you just mentioned is a lot more helpful if you were to say hunt a bug down and when fixing it sometimes the small comment about why the +2 instead of +1 can be a lifesaver so you don't break 10 other features in order to fix one.

 

[Quitta]

In my opinion, a programmer also has to master:
- The most commonly used design patterns (Factory, Singleton, Visitor, MVC, decorator, ...)
- Refactoring possibilities of their IDE. ( It can really save you a lot of time ! since development is a cycle of coding -> refactoring -> coding -> ... I was amazed by the variety of refactorings that some IDE's offer)
- Knowledge on algorithms and their space/time complexity (big oh), this makes it possible to make good design decisions.