Comment by humanfromearth9 | Hacker News Reader

Comment by humanfromearth9 | Hacker News Reader

Parent Full thread

humanfromearth9

I'll speak for software development, but in principle it's the same for any other domain.

Read about your technologies. A lot.

When I started working (about 3 to 4 years) , I spent 20-30 minutes a day reading DZone articles about Java, software design, architecture, OOP. Persist and do it daily. Repetition and habit are key.

And be focused. Understand everything in every article, do not accept not understanding everything. For each article, try to find out whether it makes sense, try to understand what the author wants to tell you. Think about how you would have done it. When possible, apply what seems to be useful and overcome the limitations of what is written /proposed in the article.

Occasionally, do the same with IT books instead of articles.

Then explore further, for example, find out how certain popular OOP patterns may be replaced by other, equivalent, patterns in FP. Think about how OOP classes are equivalent or not to closures in FP.

Also, become an expert in fundamental practices, like transaction management.

Application of theory is key.

That's how you do it.

> Application of theory is key.

I often see people either get caught up in theory without practice, or proclaim that it's all about experience. Actual time spent writing code is probably the most important thing, but having some foundational ideas and getting to skip some things you've have to painfully learn yourself by reading and then getting to apply them directly is huge.

There has actually been some research on this. I didn't save the link, but the paper I found showed that time spent reading code is a much stronger predictor of skill development than time spent writing code.

I'm guessing in practice it's probably comparable to music and language learning, which seem to work similarly in this respect. You do need to spend time practicing by doing, but having that be most of your skill development time is sub-optimal for people who aren't already at an advanced level. Most your time should actually be spent carefully observing what the experts are doing. Because that's what builds the intuition you need to critique your own performance. Which, in turn, acts as an enormous force multiplier for your active practice.

That's arguably why contributing to open source projects is such a great method. Because, unlike drilling yourself on practice problems, the vast majority of time spent contributing to an existing project will be spent reading and understanding the code that's already there.

I believe it was Knuth who said practice informs theory and theory informs practice. You need both.

And there's an adage updated with modern understanding "Perfect practice makes perfect" . It's not just repetitions but ensuring you train the patterns you wish to do automatically next time.

Excellent code is slow to write, the first 10 times, but eventually it's just as fast as junky code.

You should keep in mind that code quality is mostly subjective.

You can create a PR that coworker 1 loves because it hides the complexity and then have coworker 2 come in and say that it's complete garbage, because while the complexity is hidden, it still has to be understood in this context, only increasing the difficulty of working with the project

I.e using a state-machine vs a switch/case to determine a status attribute.

Both viewpoints are valid. Some code is objectively terrible, but most discussions on code quality are massively overblown

There are also those who view obscure and quasi-obfuscated ways of solving a problem as "elegant" as opposed to more straightforward and easy-to-read ones. Usually found near the ones ranting about superfluous code comments.

Or making/sharing LinkedIn posts showing the uber-obscure or complicated "Senior Developer Solution" next to the more straightforward and easy-to-read "Junior Developer Solution."

See the recent threads about Heaviside and Category Theory for interesting perspectives on practice informing theory (Heaviside) and theory informing practice (Category Theory naturally).

Not just time spent writing code but variety; the 1YOE ten times trap of some 'seniors' is very real.

> Understand everything in every article, do not accept not understanding everything.

I’d be careful with that. It’s a great way to get lost down the rabbit hole and works against being focused. Eventually you have to get to a point where you say to yourself that it’s someone else’s problem beyond here and double back.

> And be focused. Understand everything in every article, do not accept not understanding everything.

I read my first programming books that way. Always ask "Why is that word here" and "Why is that ! there". Made me see details.

> Application of theory is key.

What works for me is deliberately testing something that I recently read in a project. Even if it is something that works, rewrite it from the perspective of what you just learnt.

This makes you look at problems from different perspectives. And if you get stuck, it's easy to ask for help.

Reply on news.ycombinator.com