Ask HN: Top rules as a good-developer to stay on top of your game
edit: Although I originally intended this question to full stack web development - answers from any domain developers are welcome. (Minor changes to sentence)
Full-stack / web app development have a lot of moving pieces and these evolve at amazing speeds. As a developer/startup how do you stay on top of your game with these evolving pieces ?
Im new to web development and looking for top 5 rules from battle-hardened developers, mainly, how do you keep evolving products-teams-yourself ?
47 comments
[ 2.8 ms ] story [ 97.8 ms ] threadFirst, 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.
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.'
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'.
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.
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.
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.
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.
> Ask a professional musician how they got better, and [...] they'll say by doing focused practicing.
How does focused practicing look for programmer?
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...
I think getting better at programming has more to do with learning patterns, thinking carefully, and hard-won experience.
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.
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'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.
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 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]
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.
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.
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?
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.
If you're especially lucky, you may wind up with an employer who lets you open source some of what you write. :-)
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.
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.
I'd like to tack onto number 3 though: 3a) Don't try to learn everything. Being a jack of all trades and a master of none isn't the solution. Be able to write good code / thoroughly utilize the technologies and frameworks that you DO know. Then progress from there.
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.
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 :)
http://projects.ict.usc.edu/itw/gel/EricssonDeliberatePracti...
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].