loading...

Things All Developers Should Learn In College

Ryland G on July 15, 2019

Forget About "Lines of Code" Source As a developer, you'll hear a lot of crazy, unbelievable theories about what "lines of code" sign... [Read Full]
pic
Editor guide
 

"The notion, that a language comparison could be reduced down to a single sentence is almost insulting. They're languages, not Pokemon".

Thats so fucking true! Thanks for that!

 

BUT...I GOTTA CATCH EM ALL.

ash

 

Well, the rating of books by number of pages can actually work quite well in Samuel Clemens' sense of it - I wrote you this long letter because I had no time to write a shorter one. Pretty much the same with code - each new line of code is a liability, not an asset. That would be indeed something good to teach right from the start though I'm not holding my breath for it to happen.

Re languages, there are some that are the "anti-tool" - instead of supporting your thinking, they burden you with more and more. Whether that's bad or good might depend of course on your measures and ultimately on your ethics, sure. But speaking of things to teach, I'd say it's very useful to get to know the difference between "it feels fast" and "it is fast". Not as easy as it sounds though, granted.

 

Well, the rating of books by number of pages can actually work quite well in Samuel Clemens' sense of it - I wrote you this long letter because I had no time to write a shorter one. Pretty much the same with code - each new line of code is a liability, not an asset. That would be indeed something good to teach right from the start though I'm not holding my breath for it to happen.

That's a good point but I think even between languages it may not be true. I think that unless 'lines of code' is specifically relevant to the context of the discussion, it should be avoided.

Re languages, there are some that are the "anti-tool" - instead of supporting your thinking, they burden you with more and more. Whether that's bad or good might depend of course on your measures and ultimately on your ethics, sure. But speaking of things to teach, I'd say it's very useful to get to know the difference between "it feels fast" and "it is fast". Not as easy as it sounds though, granted.

I think popularity filters these out for the most part. Obviously there are obscure unusable languages (like brainfuck), but those aren't going to be a common part of your day.

I'd say it's very useful to get to know the difference between "it feels fast" and "it is fast".

I would consider myself a "low level expert" and I'm not even sure how you could generically learn such a thing.

Thanks for contributing so many new ideas to the discussion. Glad you liked the post!

 

(Hm, how do I cite a part of your comment? )

Re "popularity filters these out for the most part" - how do you figure this?

I'm genuinely curious about this because in my experience popularity is more of a counter-indicator really (as a well-known example think qwerty vs dvorak keyboards, to take this on more neutral ground). And if anything, I'd add to the list for teaching precisely this: stay away from today's popular unless you really are more into fashion than into building up a lifelong career.

:thumb:

"popularity filters these out for the most part" doesn't really explain JavaScript.

But I guess that's the "for the most part"... part ;)

Diana,
Your comments are very wise.
However, considering popularity to be a counter-indicator to the ability of the language to support your thinking process is, in my opinion, an extreme view. That doesn't mean you can't find exceptions.

 

There are very few cases where the language choice actually matters.

Spoken like a true Blub programmer... 😉

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

-- Paul Graham, Beating the Averages

 

Totally agree with the "StackOverflow density" metric of language evaluation. If someone says "language X is better than Y because StackOverflow density" it's perhaps the only such sentence I'd take into consideration.

 

StackOverflow density has really become a metric for the success of a software product. Glad you appreciated that part! Thanks for reading.

 

A problem that I see a lot when giving talks in Asian universities is teachers making their students learn languages off by heart.

For instance knowing all the functions on the String object and the parameters they can take. In my opinion this kind of teaching brings a fundamental flaw to those students. They are never taught to do any type of problem solving. They do not get any programming tests most of the time but only off by heart tests about the languages.

This brings a serious lack of understanding on how to code and when interviewing some new candidates for our company, many couldn't solve simple programming dilemmas.

I think you should remember to always try to think outside of the box and to understand basic concepts such as loop, comparisons and more.

 

I don't understand how the title connects with the article at all. If you professors thought you the opposite of what you said here... where in the world did you study?

I've never had anyone tell me that lines of code matter in a sense that it makes software better or worse, or that we're supposed to type code 8 hours a day. That's literally the experience that people told me they had in bootcamps, not in the university.

 

I went to the rank 2 CS university (at least in the states, but I think world at the time), University of Washington.

 

Do your best to not become defensive during a code review, and never take any comments personally. You're not your code.

I believe that this is key when working with other programmer/s.

edit: also, thanks for your post Ryland!

 

It's definitely true. Paying attention to all these things to learn them is important but when you study usually you don't have enough time on everything useful. In such cases, you can say to specialist type my essay in order to save your free time. Well, it's one of the options at least.

 

Very good article. I fully endorse "Haskell is better than X, because aliens" 😂😂

 

I do write code more than 4 hours a day, and sometimes even more than 8, or used to do that even more than 10... I thought I have to... :)

 

While lines of code are being abused a lot, I disagree with the fact that you should forget about them and not learn about it in college.

The number of pages of a book is actually a pretty decent indication (or at least a relevant factor) when looking at how much time it took to write the book, how much space it will occupy on my shelve and how much it will cost. Of course, these apply as averages - individual books will always stand out. Similarly, lines of code gives a very useful indication (or is a relavant factor) of how long it took to write the system, and how much time/money it will cost to maintain the system, or how much time it would cost to rebuild it. These may not be relevant for day to day programming work, but as an architect or team lead, these do come in handy.

Even if you look at quality, which you single out, it turns out that many software quality metrics correlate strongly with lines of code. On average, a larger system will be more complex, have more code duplication, etc. (relatively speaking, not just absolutely). And that's not just a "crazy, unbelievable theory", but has been tested and observed looking at a large volume of systems. (I used to work at a company investigating this - read this book if you're interested).

There are of course many caveats when using this metric - comparing lines of code in different technologies can be very troublesome if not done well, for example. Such difficulties contribute to the lines of code metric often being abused and, in turn, derided or despised. But then again, that's not really different from any other metric you'll encounter. If those using it don't understand and use them properly, it's pretty much useless. And that's actually a lesson I wish I had learned in college...

 

according to my point of view, the student should learn VCS like git or something so that he can preserve his code. I personally miss the programs I created in my initial days of college.

 

Version control is on my list for the next post.

 

What a good lesson. as a first-year college student, I really appreciated it. I'm gonna share it with my friends. Thanks!

btw, so glad to see the MS Clippy. Can't remember when was the last time. I had to run a Google image search to find its name.

 

Generally good article. But the assumption that language choice in most doesn't matter is opposite to how I see that. Agree that languages are full of tradeoffs, and that is why some languages are better for one and other for second. I would never choose for example PHP for anything more than web server app, I would never choose Scala for Android development as it has very low support there. Also languages have specific concepts of design, for example writing FP in JavaScript is full of problems, writing FP in Elm is build into root concept of the language, and working with it is just brilliant.
In Summary - language choice is very important and has many implications, so it is very important decision

 

Great writing as always!
In our case we had a pretty strong debate over the choice but for productivity’s sake.
We started as a team of three, two of us know Go pretty well and another is more proficient with JavaScript/typescript, and he reasoned we should all use one language so that everyone can take over other people’s tasks. While it makes perfect sense, any new language has its learning curve and small bytes you may or may not like. I still think that for someone to be productive he they should use whatever they choose that make them happy as long as it’s within the confines of a standard language. Still, I fully get the team leader’s view.

Long story short, typescript it is :)

 

To respond to your work hours comment, I do think people should only work 4 hours a day, and only 3 days a week. It's healthier, makes people much happier and leaves people with more time to do their own projects, in and out of tech. Unfortunately most businesses don't see it this way and basic income isn't yet established so we can't get there yet, but I'm hoping we will in the near future

 

There's valuable information here. I suspect these things aren't taught in college because (at least in my case) the vast majority of professors are researchers and not company employees. Research is work too, sure, but its work culture is different from that of regular companies.

 

Great Read! Thanks!

 

Nice addition. We wouldn't want people to think we were not working on our craft while not programming. (Which is what you should be doing)

 

Great read!

Why would someone ever write intentionally slow code?

You wrote:

"Code shouldn't be un-performant (don't write intentionally slow code)"

 
 

The data points in the disliked languages graph look like tie fighters

 
 

Haskell is better than X because FP.

 

Thank you it was really useful post, I am just going to start my bew course, so your kinda checklist will help me be focused more. I just ordered my paper from phdessay.com/category/descriptive/, I have ordered it to find out more about this area. This descriptive essay was also full of useful and new information for me.

Code of Conduct Report abuse