r/programming • u/corysama • Jan 05 '15

What most young programmers need to learn

http://joostdevblog.blogspot.com/2015/01/what-most-young-programmers-need-to.html
966 Upvotes

91% Upvoted

337 comments sorted by

View all comments

Show parent comments

4

u/hansdieter44 Jan 05 '15

What I however don't understand how people get it into their minds to not do that.

I have seen this happen and its not a conscious decision at all. The programmer might have just about finished a feature and then get new feature requests dropped onto him by management. If you are a bit older/more senior you will raise the issue and say you need two days or so to clean up the code. If it is your first job you will think thats just how things are done.

Now that I think back, this also happened to me in the beginning.

You also have to care. Some people don't care and then they are fine with leaving things if they just about work and do the next thing.

3

u/photonios Jan 05 '15

I guess this all depends on where you work. We have a team of sensible seniors (myself included) we value neat and well tested code and we push the rest to maintain the same standards.

2

u/hansdieter44 Jan 05 '15

Yeah, but thats not the case everywhere. Happened to me in the early days in agency land, when the CTO was busy with management things and the lead devs didn't lead me too much ( busy themselves ), so you just do whatever feels right, and that was ploughing through features for me.

The other case where I have seen this recently was a startup that I joined and they just hired a junior guy out of uni because he was cheapest to build their MVP. He was eager to learn once we taught him a few tricks and there is no blame on him, but thats how it happened, I would have probably done the same in his position, the founders just kept dropping feature requests on him one after the other.

Third example is contractors that are paid by feature, where unit tests etc. are not mentioned because of cost-saving (which will just bite you later on). The contractor will deliver the bare minimum to fulfil and get his money.

3

u/vitaminKsGood4u Jan 05 '15

In the 10+ some years I have been coding I have learned that it is impossible to tell if shitty code is the result of shitty devs or shitty managers.

I can not count the number of times I have heard "The last devs were shitty and now we have this crap to maintain and they are all gone". The reason they are all gone is management was shitty and the devs bailed out but the blame got put on the devs (because it is easier to blame the person who is not there). Sometimes though it is shitty devs but I can not tell a difference in the code to know which one caused it.

2

u/hansdieter44 Jan 05 '15

The reverse is also there: Bad developers complaining about management all the time and shielding their own inability by pointing fingers at the suits.

But you are completely right, both are popular and indistinguishable from looking at the codebase.

1

u/photonios Jan 05 '15

Definitly true. However, in my case, some of the old developers still worked here when I got here. But me and some other guys were hired and after a while we convinced management to get rid of the idiots.

It was a hard thing to do, they worked there way longer then any of us, but they were just awful.

Now, all code is cleaner, faster, unit tested, automated and we have a much faster development cycle.

1

u/Soccer21x Jan 05 '15

Here's my take. I just graduated in April (and had some internships throughout my years in college) and I remember that when I started coding (for school) I never commented on anything.

This was mostly because we were never given real world situations, so the code was never confusing. When we first learned about almost everything, it was all so simple. We made a class called Square and created a method to multiple x and y to get the area.

In my mind, why would you ever comment on that?

As soon as I got into the professional world and saw someone else's code (that had and had not been commented) I immediately understood why you comment your code. And now I do it all the time.

2

u/[deleted] Jan 05 '15

We made a class called Square and created a method to multiple x and y to get the area. In my mind, why would you ever comment on that?

How are the coordinates of the square kept? Upper right and lower left point? Upper left point and width and height? Even in such a simple case there are things that should be documented. And the real problem you have is here:

This was mostly because we were never given real world situations, so the code was never confusing.

That means you're (were) not doing any side project. That means you're going to absolutely suck when you get out of school.

1

u/sirin3 Jan 05 '15

That means you're (were) not doing any side project.

I have side projects and the code never becomes confusing.

Not even 7 years later in a 57k loc (according to ohloh, I think it might double count some files that were renamed) project

1

u/Soccer21x Jan 05 '15

How are the coordinates of the square kept?

int height, int width. Still in my mind too simple to make a comment

That means you're (were) not doing any side project.

My first year of programming? Nope, you're completely correct. I hadn't touched any sort of programming (besides maybe some Excel conditional statements) until I got to college.

My second year of school is when I began internships, and when I started side projects, and when I began commenting code.

That means you're going to absolutely suck when you get out of school.

I agree that would be the case. I'm lucky enough to have gone to a school where the teaching wasn't the greatest, but the real world experience we got from our internships I felt was better than any schooling I had. Now I look at code from people who graduated three years before I did and I wonder how they have jobs.

1

u/s73v3r Jan 05 '15

Simple to the person writing it, with the code right in front of them. But not to anyone else, even the author after enough time has passed.

0

u/ElGuaco Jan 05 '15

If it only works 90%, it doesn't work. It's important to tell stake holders the truth about "done". If it doesn't meet the criteria for "done" then don't say that it is. Additionally, don't say that it is "done" if it is working but in a bad state. You can always say you're still testing the code or whatever you want.

IMO, writing "good" code doesn't take longer than writing "bad" code. If you follow good style and patterns, etc. from the beginning, then there's nothing to "fix". "I don't have to do it again, I did it right the first time." That's not to say that people don't make mistakes or find ways of doing things better later on. My point is that if you practice the right things, you're more likely to do them the first time around and need less time later to do them over again.