Five Ways To Write Better Code
brandonsavage.net
brandonsavage.net
But I've never noticed this in my experience. Moreover, whenever I come back to a language after any time away from it, I'm amazed how much time I spend remembering (or looking up) superficial differences.
Stuff like looking up whether I get the length of a vector with "len" or "length" (for a language I already knew) just feels like a distraction.
So much is looking at things in a different way, and a quick way to do that is by picking something across the metaphorical language town, rather than the language next door.
I'm a better iOS developer today, because I learned how awesome blocks can be from Ruby. Same goes for meta-programming.
Languages usually have features that span everything you do in that language. Getting comfortable with blocks in a language that uses them as a primary/native data type shows me how useful they can be in a language that uses them more cumbersomely.
That's how I've benefitted from learning multiple languages. As well as the fact that I will avoid Java/.NET because they and I don't agree! :D
And suggesting a 1000 hour investment is a lot different than suggesting a 100 hour investment.
The nature of how those languages model execution, their basic paradigms, data structures and design patterns all fall within a fairly narrow scope. Stepping outside those trappings lets you see them with a bit more clarity because you're forced to stretch your brain to accommodate something altogether new and get fresh perspective on the problems the languages are solving and how they solve them.
You won't necessarily gain any perspective if you're writing the same exact kind of code in languages X and Y, and you can gain perspective by writing an entirely different kind of code in a language you're used to. It just tends to follow that when you learn a new language, you'll learn to do things in the style of that language.
Knew Java, C++, Matlab and Perl before I learned Python.
A couple years ago, I learned R... I still use that a few times a week. Don't think it's improved my python programming.
More recently learned Clojure and Javascript. I think those count as meaningfully different from Python. I program differently in those languages, but I'm skeptical they've made me a better python progammer.
I would suggest http://learnyouahaskell.com/
Maybe it hasn't, the whole idea is basically acquiring tacit knowledge and understanding through osmosis. That's why its hard to quantify how it should work.
> I’ve never taken a hard look at the Apache source code before, but I have found a few bugs in Apache that I’d love to have fixed
How can you take this advice if the author doesn't even follow it himself? Seems like a shallow recycled piece designed to promote the author's eBook.
You could think that people are smart enough to understand that they can't patch the most used webserver in the world like that, but hey, remember that Dunning–Kruger effect ?
This article does not tell people to patch Apache. The point, as for as I can tell, is to explore the projects you use so you can learn to write better code.
Then you say "they can't patch the most used webserver in the world like that"
What is "like that"? As far as I can tell it's "working with others". Although I've never patched Apache, I'm confident I'll need to work with others to do so.
The article gives good advice. I don't understand why you would jump to the Dunning–Kruger effect to seemingly assume that the readers are incapable of following the advice.
You're right. But saying something like "I’ve never taken a hard look at the Apache source code before, but I have found a few bugs in Apache that I’d love to have fixed." is like launching a stick in front of a dog.
>The article gives good advice. I don't understand why you >would jump to the Dunning–Kruger effect to seemingly assume >that the readers are incapable of following the advice.
It's a book about php. Don't tell me about Composer, Symfony or other things that 0,1% of php coders are using. Php coders don't read, they cut'n'paste.
Existing projects already have most of the code already written. A typical open source changeset is maybe 3 +'s and 5 -'s. Mostly contributing to open source projects will improve your people/communication skills because most of that you'll do it is talking to existing developers to understand the problem/how to debug the problem.
You mean Apache httpd? :)
Realize "Apache" means the Apache Software Foundation, which is made up of a large collection of open source projects.
(disclosure: Apache CloudStack contributor and PPMC member)
I'm not sure writing tests makes you a better developer...gives you better habits, but not sure it results in your code being better, compared to things like fixing bugs in others code and learning a new language.
The learning a new language holds true past software development - when I learned Spanish in high school, my understanding of some of the stranger forms of English (say, past participle) improved.
Writing a test requires you to think about your code in different ways than just creating it. TDD requires you to plan your code. And the more code you write, theoretically, the better your skills will be.
Now, will it make you the best developer? Probably not. I doubt writing tests is the most productive use of time. But for the practice of software development, writing tests is critical.
Third, it's a nice habit to have if you work on a larger project.