Live data from Hacker News

Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?

news.ycombinator.com

21–30 of 114 posts

Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?

#21
I liked what I first heard described as "t shaped" people when I read the Valve new starter guide [0]. That is people whose experience covers a fair amount of breadth with pockets of depth. The breadth is good because knowing a lot about what is out there helps you know where to look when you encounter new problems. Depth is also good because you don't really develop your understanding of how things are put together and what the challenges are until you get into a lot of detail. Multiple areas of depth, particularly where they are related (say knowing oo and functional style programming well) are particularly useful because what you learn in one area expands on what you learnt from the other. You can start to really understand what the design trade offs were and what works well in different situations.

There isn't one right answer though. The answer depends a lot on what you want to do. Do you want to lead a team, become an architect, go contracting, become a consultant, go into academia, join a Google, join a start up, write financial software, help cure cancer, invent new ways to do things, become an expert? There are lots of ways you can develop a career in software and whatever happens will most likely be part chance.

Don't worry about it too much, except to make sure you don't get too comfortable in a particular area. If you keep trying to challenge yourself and doing things that are interesting, you will keep getting better. Doing things that are interesting to you is important because it'll help you avoid getting too hung up on what everybody else knows and will help fuel you through the parts that are painful or tedious.

[0] - http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p...

Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?

#22
Programming languages matter some, but algorithms and data structures matter a hell of a lot more.

While it is true that learning different programming paradigms can help you evolve as a programmer, I strongly believe (I have been programming professionally for about 20 years) that that is far from the best way to evolve as a developer, and learning algorithms and data structures will help you "level up" faster and better.

The reason is simple. Programming languages are a medium of transforming programmer intent into something the computer can execute (perhaps indirectly). This is not an easy task by any means, but all an ideal (nonexistent) general purpose programming language can hope to achieve is the reduction of what is known as accidental complexity. Programming languages vary only in how much burden, and -- just as important -- what kind of burden they place on you when you commit your chosen algorithm from your mind to code on the screen.

Knowledge of algorithms, on the other hand, will help you tackle the far more important essential complexity of the problem at hand.

So, in a way, focusing on programming languages is indeed a distraction, at least as long as you haven't yet familiarized yourself with the more fundamental -- and more useful -- tools of computer science.

Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?

#23
post #22

Programming languages matter some, but algorithms and data structures matter a hell of a lot more. While it is true that learning different programming paradigms can help you evolve as a programmer, I strongly believe (I have been programming professionally for about 20 years) that that is far from the best way to evolve as a developer, and learning algorithms and data structures will help you "level up" faster and b…

Also programming languages and frameworks quickly go out of date, while the fundmentals like algorithms help you out no matter which language you're working in.

Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?

#24
I don't see these are in conflict at all. Both talk about spending the long period of time needed to attain Mastery. Mastering concepts is essential but mastering your way of working so as to maximize your productivity and the effectiveness of your practice is equally important. You do not want to be a dilettante who knows everything but produces nothing of substance or value.

I wrote a book specifically on how to go from good to great or at least how to become the best you can be... targeted to developers in the first 5 or maybe even 10 years of their career.

Level Up! How to Become a Great Professional Software Developer

https://leanpub.com/level_up

None of it has to do with any specific language or platform. The techniques I describe are not the only way to do it but I guarantee if you take at least some of them to heart, you will improve a great deal. I do espouse going deep on at least one platform or stack for at least several years. You might even get so formal as to build a competency map to track your progress. Much of what you learn is transferrable. 10 years or 10,000 hours will get you there no matter what but following the techniques I describe will get you there faster.

Steven Talcott Smith, Master Developer, Chief Happiness Officer, ÆLOGICA

http://aelogica.com | Great Rails teams for hire

http://appexpress.io | Rapid Application Development

Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?

#25
Wow, I'm quite literally floored by what is completely and utterly missing from this entire discussion: The User.

It doesn't matter what or how you program, as long as you have: The User.

If you have to spend your time competitively learning some new-fangled slippery, slidey, pretty little ball of tangled chains of bits and pieces of - whatever - it doesn't matter for a fig if you don't have: The User.

With The User as the principle focus of your goals and career as a developer, programmer, coder, hacker, binder-of-pretty-gthings, you can escape all misery and just learn to enjoy the ride completely. Because its The Users' bus, and if you don't have The User driving it, it ain't going no-Where.

So the whole perspective about Industry standards and real reasons for just using one thing, and one thing only, and sticking to it and becoming good at it: this is only ever acknowledged, worth a fig, if you have: The User. I've still got users of 20+ year old software stacks that I'd love to replace with some newfangled jangle. Have you?

That is how you prepare yourself for a career, in service of The User.

Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?

#26
In the venerable 'well actually' StackOverflow tradition of not answering the question: as a developer, don't consciously invest too much of your time trying to become a better developer.

Instead, set aside time to become a better marketer. If you're a solo developer you will need to get the word out to investors and customers about yourself and what you can do. Working for someone else, you'll additionally have to sell your ideas to your co-workers and management.

Even in just asking this question, you are demonstrating motivation to do your best as you create. However, your creations will typically be far better served by your ability to promote them.

Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?

#27
post #18

Whenever a question like this comes up among the people that I am mentoring, I like to show them the "T-Shaped Employee" section of the Valve Employee handbook [0]: "We value “T-shaped” people. That is, people who are both generalists (highly skilled at a broad set of valuable things—the top of the T) and also experts (among the best in their field within a narrow discipline—the vertical leg of the T). This recipe is…

I think this is the key. It's more wise than it may seem at face value. It's important to recognize the importance of both deep specialization and a broad understanding and ability to connect the dots at the same time.

Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?

#28
post #18

Whenever a question like this comes up among the people that I am mentoring, I like to show them the "T-Shaped Employee" section of the Valve Employee handbook [0]: "We value “T-shaped” people. That is, people who are both generalists (highly skilled at a broad set of valuable things—the top of the T) and also experts (among the best in their field within a narrow discipline—the vertical leg of the T). This recipe is…

It just sounds to me like they're saying they only want engineers who already know everything about everything. Sure, I'd want that too if I were hiring, but it doesn't seem very realistic.

It also makes me wonder about their ability to manage people with different skill levels and areas of expertise. And of course, having used Steam, I'm not at all surprised.

Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?

#29
The musician analogy is poorly chosen. Playing an instrument is a highly physical, hand-eye(-mouth)-coordination challenge.

But mastering a platform - be it a language, a framework, a library - will help make you a much better developer, it is true. If you don't know enough to exploit the relevant features of the platforms you're using, you'll produce a poorer solution than otherwise. You'll use more code, or fail to encapsulate. Your solution will be harder to maintain and adapt.

But then again, if you're busting your ass writing parallel applications in C++, managing locking and threads, when you could be using actors in Akka, your solution will have the same shortcomings compared to the one you could have developed had you been aware of the qualities of that platform.

So yes and no :-)

Re: Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?

#30
post #28
post #18

Whenever a question like this comes up among the people that I am mentoring, I like to show them the "T-Shaped Employee" section of the Valve Employee handbook [0]: "We value “T-shaped” people. That is, people who are both generalists (highly skilled at a broad set of valuable things—the top of the T) and also experts (among the best in their field within a narrow discipline—the vertical leg of the T). This recipe is…

It just sounds to me like they're saying they only want engineers who already know everything about everything. Sure, I'd want that too if I were hiring, but it doesn't seem very realistic. It also makes me wonder about their ability to manage people with different skill levels and areas of expertise. And of course, having used Steam, I'm not at all surprised.

That would be a square employee, not a T-shaped one.
Post reply on HN