61–70 of 100 posts
Get a job that's right for you and use it to get the design experience.
Learn a functional programming language. This has had the most impact on the way I think about systems by far. The biggest impact was realizing all of the time I've spent trying to master all of the OOP acronyms hasn't paid off. I've also realized that OOP might be meant for a type of programming that I don't do (video game logic? device drivers?), where as FP seems to fit great for Web applications that are just wra…
Erlang especially, it comes out of the box with OTP, so you don't really need to invent anything or have advance knowledge of design principles. Learn OTP, do things the OTP way. I recommend Erlang and OTP in Action by Logan, Merritt, and Carlsson. I've also heard that Joe Armstrong's latest book is really good. You can also work through the "Learn you some Erlang" exercises online.
The thing about Erlang/OTP isn't just that it's a functional language, but that--for a beginner--it's very small and practical. I describe it as "a functional language written by people whose jobs depended on it".
OTP (effectively, production runtime library and development patterns) is built on really sound engineering principles, and you can learn a lot from the explanation of why you build things a particular way while reading the pirate book.
EDIT:
The main reason that the functional aspects of Erlang are so cool when contrasted with Haskell or Scala or whatever is that they are so deeply tied into how the language functions in a production setting. It's not a matter of "my, how clever", but more of "oh, that makes implementing this reilably a shit-ton simpler".
As an example: actors in Erlang (processes there) are implemented as side-effect free functions which accept messages and manually pass state around. As a consequence, we get code hot-loading for free--you can simply swap out the update functions and run a helper to update the actor state before resuming it's run cycle using the new update function.
That's wicked cool, and is something that just falls out from the pragmatic language decisions made earlier in its history.
http://www.aosabook.org/en/ "Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well—usually programs they wrote themselves—and never study the great programs of history. As a result, they repeat one another's mistakes rather than building on one another's su…
http://www.aosabook.org/en/ "Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well—usually programs they wrote themselves—and never study the great programs of history. As a result, they repeat one another's mistakes rather than building on one another's su…
But I'd say in my oh 10-15 years of programming I've learned that the way to really learn the importance of a pattern is by deriving why it is really needed. You can't really make shortcuts there.
The difference with software is that it's soft. We're not actually creating buildings. Yes we ship products so it's related. But it's more on the spectrum towards disciplined writing or math than architecture in the traditional sense.
It's actually more to your advantage to learn via practicing with the minimum tools for the job.
Anyway, still important to learn others' patterns. But it's less meaningful in terms of how it fits in your mind -- in particular, knowing when to apply them in the future -- than deriving them on your own.
And there's less risk in learning via mistakes unlike with building physical things. Software just has faster iterations.
In a way, you're almost looking at the interviewee as a teacher except they're obviously having to improvise on the subject at hand.
I'd suggest the best practice is to understand the structure of software you're interested in and write about it.
Earlier quoted context omitted.
While I don't disagree that Bob Martin presents useful information in those videos, his presentation style is... bizarre to say the least. You'll find as you watch them that the signal-to-noise ratio drops with each episode. In the last few, there's about ten minutes of useful information mixed in with about 50 minutes of cosmology lessons, tours of his house and neighbourhood, and babble amongst his various alter eg…
I asked elsewhere but perhaps I asked the wrong person. Which episodes would recommend in particular for the highest bang-for-my-buck?
http://www.aosabook.org/en/ "Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well—usually programs they wrote themselves—and never study the great programs of history. As a result, they repeat one another's mistakes rather than building on one another's su…
https://github.com/aosabook/500lines This is a repo of smaller real world applications that are 500 lines or less in length, so as not to be overwhelming to novice / intermediate programmers.
Here is the detail description and PDF book http://msdn.microsoft.com/en-us/library/ff650706.aspx
It is targeted towards .NET developers but equally good for JVM, NodeJS etc.