Hacker News Reader

Comment by sergiotapia | Hacker News Reader

Going to be a bit unpopular here, but what the hell.

To be a great software developer you need to work on pet projects for yourself and for others. Some people do the 9-to-5 and that's fine. But those are going to be your median developers. Not your great developers.

Nothing wrong with that.

Great software developers are great because they sharpen that edge for fun. They straight up love writing code.

When you work on pet projects you research new tools, new ways of doing things, and broaden your horizons. You open source stuff, forcing you to write clean code with proper documentation.

That _directly_ influences how you write code for your job. That knowledge applies in strange and unexpected ways. In my experience you end up using a lot of the new stuff you pulled in through your escapades.

You want to be a great software developer? Write open source code. Read open source code.

View on HN

You're perfectly capable of being a mediocre (or terrible) developer while writing code from the time you wake up to the time to go to bed.

The way to actually get better (at anything) is to create a feedback loop and focus on the bits and pieces which matter.

Ask a professional musician how they got better, and you won't hear them say "by playing the piano for 16 hours a day, every day". They'll say by doing focused practicing. And that can be done in anywhere between 2 and 6 hours a day.

Even at your day job...

You want to be a truly useful software developer? Expand your knowledge beyond software development by doing more than developing software.

yup. I worked at a place where they would constantly write code. lots and lots of shitty code that never should have been written. issues scaling postgres -> rewrite active record to use the latest nosql db. issues with that -> rewrite the app again.

there's a difference between just writing lots of code and understanding what your doing. I like the approach of writing katas every day until you've really internalized the technique you're working on.

> The way to actually get better (at anything) is to create a feedback loop and focus on the bits and pieces which matter.

> Ask a professional musician how they got better, and [...] they'll say by doing focused practicing.

How does focused practicing look for programmer?

Google brings up this:

http://artists.pixelovely.com/focused-practice-an-exercise-f...

Step 1: Identify what you’d like to be better at, and be specific.

Step 2: Try to break this goal down into smaller goals. List them. Notice if one might interfere with the other goals if it isn’t tamed first. Choose the most foundational goal.

Step 3: Commit to practicing that aspect of drawing 100 times. Each practice should take a minimum of 5 minutes.

This is for drawing but it looks like it could be adopted for programming.

EDIT: googling some more brings up this article https://sites.google.com/site/steveyegge2/practicing-program...

EDIT2: even more googling finds more concrete focused practicing http://web.archive.org/web/20060316094755/http://blogs.pragp...

Don't you think the emphasis on repetitive practice makes more sense for skills that are based on bodily coordination?

I think getting better at programming has more to do with learning patterns, thinking carefully, and hard-won experience.

You're missing feedback. If you don't get regular feedback, all the thinking and patterns in the world aren't going to help you learn.

Feedback does not need to be external; it can be driven by the requirements you set forth for yourself. "I want to learn to build in low memory environments," leads to "This backend must never use more than 1MB of memory." "I want to figure out how to optimize programs," leads to "This backend must respond to every request in under 50ms." "I want to know everything about my current programming language," leads to "Obfuscate Hello World!"

Create a feedback loop and write simple programs, each time with different criteria. "I can only use functions," or "This must be as fast as possible," or "this must be as slow as possible (without using sleeps)"... the possibilities are many, and the time required is small for each exercise.

They make for great 20^H^H1% projects or "I need to step away from my current program" tasks.

Well, I thought of feedback as part of "hard-won experience", but yeah.

You invert a binary tree for fun

Exactly.

If you wanted to be a great musician, athlete, or whatever, you would practice when you're NOT performing. It's a combination of developing the muscle memory, experimenting with new ideas, learning from other people, teaching others, and replacing bad habits with good ones.

There's no way to do that other than just doing it.

If your priorities are elsewhere, no problem but realize that little differences (salary, skills, exposure) compound over time.

I second this. I learn a lot at my 9-5, but I learn much more building small side projects where I have to do every piece of it myself, rather than just my part and off-put it onto the next team. Additionally, I've learned more than I can credit from simply reading open-source project code. You'd be surprised what weird little tricks you'll find in there.

I find that on pet projects I almost never learn new tools. I tend to have an idea that I want to try out, and I use the tech I know to get there quickly. It feels a bit sad, I must admit.

Interesting, I've had the exact opposite experience. When I'm working for someone else, I feel like I need to stick to the tools I know. But when I'm working on my own project, I have an itch to try out the latest and greatest thing, even if it's irresponsible to do so and will only slow me down.

I'm not sure what would be unpopular about this. It's totally true. When you aren't charging a bazillion dollars an hour to write software, there's much less pressure to hit deadlines. And generally speaking most people perform better on cognitive tasks like programming and learning when they don't have a gun to the back of their head.

If your employer is willing to subsidize your learning, count yourself extremely lucky. Most companies don't have the luxury to do that. They're pressed for time, so instead of having you learn the right way to do something, you tend to get pushed towards quick implementations that 'will do' for now. Even companies with the best intentions face this problem because their clients will set some arbitrary deadline that they have to stick to

When you're on your own time, you can relax and explore the subject matter in depth. It's this process of exploration that will make you better.

Just remember that it's a selfish world out there. Nobody cares if you're getting better as a programmer. If you want to get better, you have to invest in yourself.

"working extra hours at something will make you better than someone who doesn't work extra hours"... of course.

It's a secret so use wisely! Don't crash the market!

I don't fully agree with this quote/statement. There is something to be said about proper rest and non work hours as your brain does it things.

I'm sure most people here can attest to the anecdotal proof of having a difficult problem and leaving it. Then it suddenly coming to you some point later during non work. This also applies to developing skills. Not just problem solving.

I'm hoping you're being sarcastic, because in my little world that has never been true.

My observations say the correlation is pretty much the other way around: You work more hours because you can't get the stuff done during your allotted time. You're not learning new stuff, you're doing the same you've been doing the previous 8 hours of that: Struggle.

Of course there is brilliant people that just enjoy their work and stay longer every day; but staying longer is not the reason why they're brilliant. Being brilliant, specially on a trade that has a strong creative component, it's not something you can always train. Or at least not by repeating the same tasks over and over.

I think is this more "working extra hours at something" where something is "generic coding" rather than "a specific task I'm working on at work"

I think you misinterpreted my statement. My point was that working on side projects in your own time is the equivalent of working free overtime.

Thank you both for the clarifications!

I see your point and I agree that side projects could help increasing your skills and/or knowledge. However, I'm not sure they're an effective way of doing that or if we [tend to use mostly the skills we have / tend to learn skills that are so different than our daily jobs that can't be applied or aren't useful for professional development]

Reply on news.ycombinator.com