Disqus - Friends of sanatgersappa

Re: :jasonrudolph => :blog >> Programming Achievements: How to Level Up as a Developer

Rich Hickey — Mon, 15 Aug 2011 12:56:54 -0000

Sorry, I have to disagree with the entire premise here.

A wide variety of experiences might lead to well-roundedness, but not to greatness, nor even goodness. By constantly switching from one thing to another you are always reaching above your comfort zone, yes, but doing so by resetting your skill and knowledge level to zero.

Mastery comes from a combination of at least several of the following:

Knowledge
Focus
Relentless considered practice over a long period of time
Detected, recovered-from failures
Mentorship by an expert
Always working *slightly* beyond your comfort/ability zone, pushing it ever forward

Imagine your proposal recast:

* Writing Achievements

** Learn a variety of languages

Learn Chinese
Learn French
...

** Experience the ins and outs of various platforms

Write a book review
Write a product catalog
Write a comedic screenplay
...

** Enhance your understanding of the building blocks that we use as writers

Write in the first, third person
Write poetry
...

** Write in the open

Blog
Tweet
Publish essays
...

** Teach

Conduct a writing workshop
Tutor students in writing
...

These are largely the activities of beginners and students, not practitioners nor masters (or, in the case of teaching/publishing, people who should already be practitioners/masters). N.B. I am not questioning the many benefits of broadening or learning activities, just the premise that they lead to any sort of mastery.

Musicians get better by practice and tackling harder and harder pieces, not by switching instruments or genres, nor by learning more and varied easy pieces. Ditto almost every other specialty inhabited by experts or masters.

One can become a great developer in any general purpose language, in any domain, on any platform. And, most notably for the purposes of this discussion, such a developer can carry that greatness across a change in any of them. What skills then are so universally useful and transportable in software development? Two are: the ability to acquire knowledge, and the ability to solve problems.

How does one get better at acquiring knowledge and solving problems? Not by acquiring a lot of superficial knowledge nor solving a lot of trivial problems (a la your 'achievements'), but by acquiring ever deeper knowledge and solving ever harder problems.

You should take heed your phrase 'leveling up'. You don't level up by switching games all the time, but by sticking with one long enough to gain advanced skills. And, you need to be careful to recognize the actual game involved. Programming mastery has little to do with languages, paradigms, platforms, building blocks, open source, conferences etc. These things change all the time and are not fundamental. Knowledge acquisition skills allow you to grok them as needed. I'd take a developer (or even non-developer!) with deep knowledge acquisition and problem solving skills over a programmer with a smorgasbord of shallow experiences any day.

Will this lead to an as-easily-realized improvement strategy based upon boolean achievements? Probably not.

Re: Thoughts About Datomic

Rich Hickey — Tue, 03 Apr 2012 14:21:55 -0000

I think it's important to distinguish data locality from disk locality. It is only the ongoing focus on disk locality that I am calling into question, and that Datomic is looking beyond.

This paper offers an interesting perspective:

"Disk-Locality in Datacenter Computing Considered Irrelevant" http://www.cs.berkeley.edu/...

Re: Clojure/core — (take 5 daniel-spiewak)

Rich Hickey — Fri, 20 Apr 2012 07:03:45 -0000

conj is not a sequence function, it is a polymorphic 'conjoin' function and works with sets and maps as well.

Re: Clojure/core — Reducers - A Library and Model for Collection Processing

Rich Hickey — Tue, 08 May 2012 16:30:56 -0000

Fixed - thanks!

Re: Clojure/core — Reducers - A Library and Model for Collection Processing

Rich Hickey — Tue, 08 May 2012 17:56:44 -0000

No solution yet, no. Multi-reducibles will be reducible but not foldable (i.e. not amenable to parallelism). Multi-foldable is, I think, still a research problem :)

Re: Clojure/core — Reducers - A Library and Model for Collection Processing

Rich Hickey — Wed, 09 May 2012 08:29:09 -0000

Yes, except the bottom operation is reduce, since map/filter etc are now just reduction transformers, and we call the next operation combine, since its inputs are reduction results. map/reduce becomes reduce/combine.

Re: Clojure/core — Anatomy of a Reducer

Rich Hickey — Wed, 16 May 2012 11:10:58 -0000

No, reducing is a one-shot thing. What you are describing is already covered by the lazy sequence functions.

Re: The Proper Pronunciation of Clojure's Assoc - Squid's Blog

Rich Hickey — Tue, 29 Jul 2014 21:52:31 -0000

It's assosh, as in assoc(iate) this key with this value.

Re: Understanding Clojure Transducers Through Types

Rich Hickey — Fri, 08 Aug 2014 08:12:54 -0000

The transducers code in my Haskell example ends on line 10. The rest is an example of use. To consider transducers something that requires some T be Foldable or Conjable is beside the point and confusing. (I know you are not saying that, but people following along need to realize it is *only* about reducing function transformation, it is not about Foldable things) Also, while it may be convenient to factor out r, the facts of reducing functions in dynamic languages with runtime polymorphism, and of applying transducers to processes, are much more nuanced than r -> a -> r can capture. It's a convenient shorthand that when reified like this is significantly less expressive and less correct than the truth of the rules.

Re: Understanding Clojure Transducers Through Types

Rich Hickey — Fri, 08 Aug 2014 08:34:43 -0000

To be clear, I think you did a good job. The rank-2 type in particular captures an important property. I wanted as much to make a point about my code, where I didn't make the transition from transducers lib to example clear. The biggest thrust of transducers is moving away from thinking about functions from Collection -> Collection, or Xable -> Xable. If you can express your process in terms of a reducing function, you are in business.

Re: SU&SD Take on The Board Game Geek Top 100: 101-81

Rich Hickey — Tue, 23 May 2017 09:00:49 -0000

Yep, RotW will have you looking askance at TTR. Quick teaching time and so much more game there. These games have high interaction levels w/o combat or much screwage (until the top end of the line, e.g. AoS, 18xx). The board matters, the mechanics are connected. First timers have fun and gamers can chew. Train fandom not required. From RotW I'd point you right at Tramways, a fantastic game by any measure. As a latecomer to the train genre myself I'll just say - don't wait! These are among the best games I now own.

Re: Review: Gloomhaven | Shut Up & Sit Down

Rich Hickey — Mon, 18 Dec 2017 15:58:45 -0000

Yes! I take full responsibility (long story :)

Re: Things I hate about Logic Pro X and Conclusion!

Rich Hickey — Sun, 04 Feb 2018 21:29:20 -0000

This Logic series was truly epic - thanks Robert!

Re: Cubase and Me

Rich Hickey — Thu, 30 Aug 2018 08:58:45 -0000

I just wish Cubase had chunks, or even something like S1 scratch pads. Track versions and arranger are not it.

Re: Podcast #92: Matt’s Crap Trams | Shut Up & Sit Down

Rich Hickey — Wed, 20 Mar 2019 17:24:47 -0000

Tramways rocks. You are on the money about learning curve and non-obvious value props. But so much fun once you are over the hump. It's definitely worth a few more plays.