
Ask HN: Top rules as a good-developer to stay on top of your game - samblr
edit: Although I originally intended this question to full stack web development - answers from any domain developers are welcome. (Minor changes to sentence)<p>Full-stack &#x2F; web app development have a lot of moving pieces and these evolve at amazing speeds.
As a developer&#x2F;startup how do you stay on top of your game with these evolving pieces ?<p>Im new to web development and looking for top 5 rules from battle-hardened developers, mainly, how do you keep evolving products-teams-yourself ?
======
sergiotapia
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.

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

~~~
NetStrikeForce
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.

~~~
smcg
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.

~~~
NetStrikeForce
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]

------
trcollinson
I would suggest a three part method to success.

First, know what you do know and don't chase after everything you don't know.
If you are good at php, use it. If you understand rails, use it. If you are a
master of all things RDBMS, use one. When you are looking to tackle a problem,
don't look for a new technology, language, or paradigm to solve the problem.
Use what you already know, and solve the problem.

Second, solve the problem. Also, don't pick a technology and then try to shoe
horn that into the solution. In other words, when you have a new project, or
an existing project that needs improvement, don't say, "Well I am going to
need a, b, c, and d because every good project needs those!" Instead say,
"What is the problem I am trying to solve? How do I define the problem? What
value am I bringing?" Then find technologies and solutions to fit into the
answers to those questions.

Finally, learn new things incrementally. For example, maybe you are working on
a web project and need a good mobile first css framework (due to the answers
you received from the questions in the second part above). You always use
Bootstrap. You add bootstrap into the project (because you know bootstrap, see
the first part above). You've never used Sass but you'd like to add that. This
might be the right time to add it to your skill set and this project. Notice
how you didn't add a whole new css framework, a whole new application
framework, a whole new language, a new server technology, a new javascript
framework... you added one new thing incrementally. You can do that as often
as it makes sense. But never more often.

~~~
itake
I think this makes sense if you are trying to build skills to start a company
yourself, but I think if you want to ride the pay curve, you need to be more
agile when it comes to learning new tech.

It is a fact that php devs earn less than RoR engineers. If you want to stay
at the top of the pay curve, you need to stay up to date with the latest
'sexy.'

~~~
trcollinson
I am going to respectfully have to call you out on this one. First off, where
is this fact that php devs earn less than RoR engineers? I am sure there was
some who earn less and some who earn more. The point though it that if you are
aligning yourself on the latest technology, you will absolutely always lose in
the long run.

I would say I am in the top 5% of engineers by salary in my area. I never lead
out with the language or framework or cool new 'sexy' technology that I think
a business should/could/has to use. When looking for employment I never even
worry about what the company is currently using. I literally only worry about
aligning myself with their business objectives. What are the problems they are
facing? How can they decrease costs or, often more importantly, increase
revenue? Why do they need me and how can I solve their problems starting
immediately?

Now, you might say, well then you won't get hired on everywhere you apply to.
Absolutely! And thank goodness. If I walk into an interview and all the
current employees can talk about is the finer parts of minutia within the
latest build of Rails, I would rather not work with them. If all I can be
asked is how many ways you can concatenate a string in .Net and an example of
when to use each, again, I will pass on that company. (yes, I have been asked
exactly that question, and there are more ways than you think). Why would I
pass? Well they sure as hell aren't aligning themselves with the needs of
their business, how am I going to?

Trust me, if you would like to stay on the top of the pay curve, align
yourself with business objectives, particularly those which align with money.
Don't worry about the 'new sexy'.

------
mooneater
My main tips:

1) Read a lot about what is out there. Reading viewpoints helps prioritize
what you want to learn next. Talk to opinionated, passionate people and
understand why they hold strong views.

2) Experiment with things well outside your comfort zone. Eg., a language that
you may never get deep into, but can give you a new perspective.

3) Figure out what NOT to learn. There are so many new things and the rate is
increasing. I feel I cannot afford to spend a long time learning the wrong
things. So for example I focus on python instead of python+c#, postgres
instead of postgres+mysql, linux instead of linux+osx. Spreading me less thin.
But to do this you have to know why you choose X over Y, the reading and
experimenting infom you for this.

4) Learning "technologies" is not enough imo, you need to couple that with
theory to produce really powerful systems. Machine Learning, Crypto, Controls,
Discrete, whatever you are interested in. You can learn this alone, but
sometimes a course or two is the best way to beef up your theory.

5) I've come to think about digital systems having an "anatomy" similar to the
human body. Different components are like various organs. Building complete,
balanced systems requires understanding all the various types of organs.
Assume you have blind spots, and seek to discover and master the organs (types
of components) that are least familiar to you. You do this by inspecting other
systems and seeing how they are composed and how that differs from how you
compose your systems.

Very interesting to see what others say about this.

~~~
imh
>4) Learning "technologies" is not enough imo, you need to couple that with
theory to produce really powerful systems.

This is HUGE. I'm able to keep up to speed and learn more ML and stats
comparatively quickly because I have strong applied math foundations (from a
physics and applied math background) and have learned the theory behind the
stats (from lots of hard work and self study). It fits into the "work smarter,
not just harder" bucket.

If you can learn 1+1=2, 2+1=3, 3+1=4,... that's a ton of shit to memorize. But
learning how x+1 works for all x, you only have to learn one thing (kinda).
It's a rough analogy, but that's how I think of it.

------
falcolas
Learn the concepts behind the technology. If you understand MVC, you can pick
up React/Flux. If you understand callbacks, you can pick up promises. If you
understand process isolation, you can pick up Docker. If you can install a
program manually, you can pick up Chef/Ansible/Puppet. If you understand the
practical limitations of memory, disk and the network, you can grok why MySQL,
PostgreSQL, Mongo... all have the strengths and weaknesses they do.

And so on.

The downside is that you'll end up taking a look at the hot new technologies
and shake your head a bit as you see the same concepts being reborn again and
again, frequently with the same lessons to be learned.

------
hannele
Find excuses to learn things outside your comfort zone, at your work or
through pet projects.

The pet project can be easy, as long as you have the time and motivation -
pick a tech and make a small hacky thing. (I must admit to being an
unrepentant procrastinator so this is advice I have rarely followed myself.)

The work route can also be rewarding though, given the appropriate work
culture. I haven't found it too hard to take the time to learn about a thing
that is blocking my team, and in my case I've gradually built up my knowledge
of infrastructure and deployment practices where previously I'd mainly only
written code.

When you run into a bug, make sure you dive down into _why_ it broke in the
first place, as well as what. This will help you avoid [cargo-culting][1] and
can also give you some [pretty fun stories][2].

    
    
      [1]: https://en.wikipedia.org/wiki/Cargo_cult_programming
      [2]: https://medium.engineering/the-curious-case-of-disappearing-polish-s-fa398313d4df

------
aaronbrethorst
The best developers I've ever worked with are the ones who are insatiably
curious and relentlessly pragmatic. They always want to understand how and why
things work the way they do, but they also understand the need to ship.

------
ebbv
The short answer is spend some (not all) of your free time on learning skills
and self improvement. Over the last six years I've always tried to have side
projects going, I have volunteered to help other people's projects and I have
picked up a lot of skills from those. I also volunteered to attend training
and read books that I might not have in the past.

------
NetStrikeForce
Define "stay on of your game" first :)

Does it mean "keep or increase your value for your company"? If that's the
case: learn to understand the business. Try to walk in your CEO's shoes when
making decisions. It'll make your way better. You might learn a new technology
and want to apply, but does it play well with your current infrastructure? is
it cheap to maintain? will the company be dependent on your existence to fix
things?

No technology, programming language or framework would be more valuable than
understanding the business.

If it means "know about the latest buzzwords and newest programming languages
and frameworks" then I don't know, reading HN to spot the trends maybe? :)

By the way, a golden rule of the so-called battle-hardened professionals is to
let someone else fight the battles and learn from their results. In other
words, don't be the first to deploy the new buzzword in production :)

------
cdnsteve
Work with a talented team. You learn things you would never learn otherwise as
a solo dev. The human interaction side, writing more universal code. You'd be
amazed how much code makes complete sense to the author but isn't clear to
team mates.

Learning new things on your own is good. Having a good employer that
encourages on the job learning is very important. Whatever you use this year
might be obsolete the next. Action Script anyone?

Don't pressure yourself to work all the time. Maintain a healthy balance.
Eventually I think every developer goes through a period of being overwhelmed.
You can't learn it all, even if you work 15 hour days. Learning is a journey
so pace yourself.

------
dmuth
In addition to having side projects going, don't hesitate to put them up on
GitHub. That's a great way to show off your skills. And these projects don't
have to be huge, even if they are small utilities or apps that scratch a
specific itch, that's also good to show off, especially if it's for a problem
which has not been solved before.

If you're especially lucky, you may wind up with an employer who lets you open
source some of what you write. :-)

------
Rabei
Be good at learning

I don't mean technical stuff only, but the entire process of software
development is to automate knowledge.

You can't automate knowledge that you do not have.

------
tmaly
learn tricks, tips, etc on how to write code that is easy to understand and
maintain.

It is said that we spend 10 times as long reading code as we do writing code.
If you can optimize for that, it saves lots of effort over the long term.

~~~
ThrustVectoring
Yup. If I'm working with code I can understand, making changes takes very
little time. If I'm working with code I don't understand, I might be able to
hack something together that makes things even harder to understand. Probably
the best bet is to spend however long it takes to dive into it, and possibly
rage-refactor if it's too much to dig into without being the person who wrote
it.

------
x0x0
I think you need to be more specific. I don't think, except with a handful of
exceptions for really stellar individuals, that there are good developers.
Rather, there are good developers for a situation.

imo, the things that make you successful in a google or apple vs in a small
startup vs a consultant vs a one-person company are wildly different.

Which are you interested in?

------
dmessing
Look at open source code. I think it is just as important to review well
written code as it is to practice writing code.

------
torte
To actually answer your question about "how to stay on top of your game":
Don't try to keep up with all the new shiny things coming around. Focus on a
few things you want to learn and learn them deeply. This will make it easier
to adapt new things later in case you MUST learn something.

------
Jugurtha
Here's a paper that might be of value:

[http://projects.ict.usc.edu/itw/gel/EricssonDeliberatePracti...](http://projects.ict.usc.edu/itw/gel/EricssonDeliberatePracticePR93.PDF)

------
fapjacks
ABC: Always Be Coding.

