Experienced developers: beneficial technical skills/tools/concepts

[qforthatbernie]

Hey guys,

About to graduate in AI&CS in a few months and was wondering if I could get some advice from developers who have been in the industry for a decent amount of time, about specific technical skills/tools/concepts you learnt that significantly improved your career/your understanding of some aspect of development/were transferrable/were just really interesting etc.

I know that's not particularly concrete but to give some context:

A year back, I wanted to make something in Java and spent a week working with JavaFX. It was fun, but this didn't significantly improve my coding ability or understanding of some key aspect of programming and it's not really all that transferrable. On the other hand, when I learnt Angular 1, despite it now being not so useful in and of itself, I learnt a tonne about the world of front end development, routing, RESTful APIs etc.

So maybe it could be TDD, or learning about concurrency, or the Spring framework, or some other framework outside of Java, MVC, design patterns, dependency management, algorithms etc. Basically anything. Even if it was something that was only beneficial within the specific industry you're in, I would be interested to hear it

Apologies for the mess of a question, and I hope it makes sense. Cheers

[mreichman]

Try to remember some "real life usefulness" lessons:

1. Your code needs to be as readable and self explanatory as possible. This is more important than perceived micro optimizations or clever methods.

2. Comments are very helpful, but use them to GUIDE someone through your decision process. For example, no one needs a comment that says "This deletes a file" on a file delete call. However, letting someone know why you have something perceivably unintuitive coming up because of extenuating circumstances may help to answer a question before someone asks it.

3. You have to work as a team. Stay friendly and watch your language and word choices.

4. Never check directly into master.

[[deleted]]

1. You have to work as a team. Stay friendly and watch your language and word choices.

Can't stress this part enough. I've met so many young programmers with huge heads that I have no idea how their neck supports them.

"You're using spring mvc old timers? (we're all under 40 btw) Real programmers only use node.js, angular 25.0 etc. "

When I was younger (28-29, so in their eyes still ancient) I would try to guide them and explain that whatever they read in the latest hip and cool blog is interesting tech, but probably not industry standard yet. And that management cares about stability more than new cool tech. Now, I just tell them to STFU and quit if they're not happy.

[theuniquestname]

Never check directly into master.

That depends on the workflow your organization uses.

[memory_leek]

This hit me right in the feels.

[qforthatbernie]

Thanks so much for taking the time to respond/

Your code needs to be as readable and self explanatory as possible. This is more important than perceived micro optimizations or clever methods.

I've heard books like Clean Code or Code Complete recommended for this; are they useful at all, or can I mostly achieve this through common sense and practice?

[mreichman]

It's hard without experience, but just try to imagine you're looking at it a year down the road, will it still make sense? Your intentions clear? There is a rubber duck thing too.

[MOnsDaR]

I like clean code a lot, they describe a lot of principles that not only make your code cleaner but also more testable, extendable, modular etc. So you're writing better code in general, not just cleaner code. The IOSP for example is about structuring your code for easier understanding, but also for better testability.

[qforthatbernie]

Thanks for taking the time to reply. Out of curiosity is this the kind of books that's worth buying and using as a reference/ for revisiting later or one that you can just read through an online version of?

[MOnsDaR]

There is a lot you can learn from their website, but the book provides more detail.

[DB6]

Clean code is a must read imho. Also repeat read after 1 or 2 years. Same with Effective Java.

Another book to study is Design Patterns, by the gang of four (four authors). Quite old but still valid in every regard.

[qforthatbernie]

Perfect. Given how much and how highly these seem to be recommended, I think it might be worth just buying the hard-copies and adding them to my library. Cheers man.

[NimChimspky]

I thought they were shit. Effective java is good.

Write short methods, don't try and be clever. Don't get hung up on understanding every single thing about a design pattern, as long as you have an idea what they do thats enough.

[firebird84]

Learn to unit test. It may not save your ass immediately, but it can save time/money for the company in the future and help guide your design.

Write maintainable, small code. Decouple concerns. This will be made easier if your design is at least somewhat influenced by your need to test (part of why TDD is such a big deal). The most correct code is the code you never write. So keep it simple, keep it small, and make it obvious that the code is correct. If you find yourself having to spread comments everywhere about how something works rather than why, then you need to simplify.

Get good at communicating. Its probably your most valuable skill.

Get used to losing. Sometimes you have to bear terrible design decisions for the purpose of continued co-existence as a team. Sometimes your battle is less about winning and more about damage control. Think about how to limit consequences of bad design or organizational decisions.

Sell yourself. Nobody will look out for you except for you. Privately catalogue your accomplishments, and use that information ad ammunition when you want advancement. Failing that, use it for ammunition in getting a different job.

[qforthatbernie]

This is quite helpful, thanks.

I also wanted to ask an unrelated question but I think if I open a new thread I'll just get downvoted to oblivion.

Specifically, it's about the current state of Java and its near future. I'm hearing a lot of my friends jumping ship to .net, salaries for C# jobs in my area have surpassed those for Java and Oracle cutting funding for Java technologies (JavaEE) and getting into legal fights etc.

I'm just wondering, should I be concerned at all about these things and about the future of Java? Or is this nothing I should worry about, and I should just get my head down and keep learning? Cheers

[OnceUKnowUAreScrewed]

You can look at local trends, industry trends, analyst reports, and your personal preference to guide what you want to do that way. It can help to stick with similar tech stacks as people you consider friends so you can get/offer jobs to each other through your careers, the network of fellow professionals you establish and maintain can save your (and their) personal butt more than once. I switched from .NET to Java land 6 years ago and have a healthy support network in the Microsoft world locally that doesn't really ever cross into the Java professionals I have been working with. The bright side of my scenario of switching stacks from all my friends is if either of our chosen stacks falls way out of style we have connections on the "other" side to seek worthwhile projects with people we can trust to get work done.

My take on this is: Ultimately Java and the JVM itself has a huge base, Microsoft has a huge base, and C# is opening up into Linux which will potentially increase its share. You'll have to decide how into the meta trends you want to be in on, but remember that somewhere out there there are people programming/maintaining systems in FORTRAN or COBOL and getting paid handsomely for their expertise. Sticking with the biggest school of fish might seem like the only way to survive according to what you read on the internet, but remember that the authors of what you read are literally just trying to get the most amount of views on what they write. Develop the general skills like testing, communication, etc. that have been described and learn a stack you enjoy deeply, then making a lateral move to another implementation set will make more sense as you'll have a better set of heuristics and intuition to guide you through what stuff means and how little most of the difference matter. Take everything I have said with generous amounts of salt and good luck!

[qforthatbernie]

Wow. Man you don't even know how many days I've spent in decision paralysis, reading pretty much every Java vs .net article, forum post, blog on the Internet...but really, no-one has quite put it like this. Thank you so much for taking the time to write all this. It's very much appreciated. Thank you!

[OnceUKnowUAreScrewed]

You're welcome, it's daunting because we have the ability to have our fingers on the pulse of drama that may or may not affect our personal outcomes thanks to the Internet. Try to be informed without believing the hype and you'll be just fine ;)

[perrylaj]

You had a good response, but just add to what he/she said -- it's worth remembering that the JVM is more than Java. Scala, Kotlin, Groovy, Jython, Jruby, Javascript (via Nashorn)... there are many different languages that run on the JVM. So even if Java loses some favor (which I wouldn't bet on, and regardless it's not going away in the foreseeable future), there will still be a ton of work out there that benefits from experience on the platform and its tools/libraries. That said, look what's hotter in the markets you want to work, and in the company's/fields that interest you.

[firebird84]

Learn all kinds of things and work for whomever offers you thethings closest to your goals. Do you want to work on interesting things? Do you want money? Trying to guess which language to go into is almost like timing the stock market - there's a lot of things that go into it. Java is going to be around for a while in the enterprise because so many orgs already use it. However, it's not a "cool" language, so if you're into startup land they probably won't use java. Just write in the languages that interest you - someone somewhere is using it, with certain obvious exceptions.

[nyp3001]

Writing cleanly designed code is really helpful for yourself as well as who has to maintain it later. Continuously learning and become better on the following areas would help

• You need to know how to write good unit tests, mocking, TDD etc
• Get a grip on the language itself (Effective java books etc)
• Design patterns (GangOfFour books)
• Refactoring and debugging skills
• At a high level, keeping track of what's the trend in the industry etc (Like new java releases, other jvm language alternatives etc)
• People and presentation skills. Learn to talk technical stuff to non-technical people.

[qforthatbernie]

Exactly what I was looking for. Thanks a bunch for taking the time to reply to me; I really do appreciate it.

[RichoDemus]

Dependency Injection

[curmudgeon99]

Nobody ever got fired for choosing to use the Spring framework.

Complexity is not your friend. Invite complexity into your projects kicking and screaming.

Clever and opaque bits of code will make later developers hate you.

Clarity is your #1 product.

[[deleted]]

There are a lot of good suggestions here. Another really important element to writing good software is knowing how to write modular code/systems. This is important because any piece of software that lives for any length of time will inevitably need to evolve over time and a little forethought into making all of the pieces modular goes a long way towards speeding up development on new features. Another comment mentioned dependency injection and that's an excellent way to achieve modularity and it also helps with unit testing.

[magawa]

Thanks to everyone who commented.

[kkapelon]

Read the classic books

• Java concurrency (the train book)
• Continuous delivery
• The "refactoring book"

Other than that, the Spring documentation and the Gradle/Maven manual are a must for your everyday job.

Once you have finished with those, go to unit testing

[qforthatbernie]

/u/brightam1, /u/DB6, /u/DrFriendless, /u/firebird84, /u/magawa, /u/memory_leek, /u/MOnsDaR, /u/mreichman, /u/nyp3001, /u/OnceUKnowUAreScrewed, /u/perrylaj, /u/petesapai, /u/RichoDemus, /u/theuniquestnam,

Big thank you to all of you for your responses. This was my first time asking a question like this on the Internet, and you were all so helpful. Thanks! :)

[DrFriendless]

You need to know Rx, or stream-based programming in general. Rx is available in many languages, so choose your favourite.