Depends on what I need to do. Learning enough to read some code takes less time than learning enough to fix bugs. Getting to sufficient competency to write code from scratch takes longer, and leading a team and making architecture decisions will take longer still.
I can usually read any C-family language without any study, because they are much more alike than different. I will need some reference material to fix bugs and make small changes. I may need a tutorial or a non-trivial code base to study to get to competency. Before I would lead a team or make expensive decisions I would want a couple of years experience with the language and ecosystem.
Usually? Based on what evidence? Writing actual code as a member of a team is the best way to learn a new language and set of tools. What some may call “bad habits” are more accurately called different habits. We can’t, as a profession, even agree on indentation, so no habits are objectively good or bad.
I work in the public sector in a role where part of what I do is project manage/code review/consult the suppliers that build various solutions for our different areas of business.
And you really hit the head on the nail with this one. Almost no company that we’ve worked with do things even remotely similar. Which is all right, if what they are doing works for them and produces stable products at a reasonable price and timeframe, then who really cares how they do it?
It does make for some interesting codebase transfers with modern public sector enterprise architecture though. Like when a major system goes from one IBM sized operator to another, because the winning bidder changed hands. But that’s another story, and it really just underlines what you say, because even huge international tech companies don’t remotely agree on practices.
I think our failure, as a profession, to recognize and accept different ways to solve problems holds us back. Programmers almost always dismiss legacy code and anything they didn't write as crap, even if it works and adds business value. There's always a better language, toolkit, paradigm that the original developers should have used. We're good at pointing at mistakes and speculating on how we could have done it so much better, but not very good at honestly studying and learning from someone else's code.
Programmers who carry around the idea that they alone know how to write the first ever perfect piece of software, if only everyone would listen to them, cause more damage than the people cranking out working but imperfect code. The perfect is the enemy of the good, but we never seem to learn that.
I see this play out in my own work -- I specialize in legacy and abandoned applications. I'm often told by my customer that several developers looked at the code before me and declared it crap, unmaintainable, have to start over with (fad of the month) language. Yet the code works and has been maintained and enhanced for years or even decades (the opposite of unmaintainable). Ugly, yes. Requiring some commitment and study, yes. But not so terrible that starting over from scratch (which almost never works out as predicted) is a good business proposition. Call it hubris, call it fleecing unsophisticated customers, but this attitude just keeps software development reinventing the flat tire in different languages, to paraphrase Alan Kay.
Based on experience. I don't mean things like indentation. I mean things like on http://thedailywtf.com/
One company I joined put all their database types as strings because it was most flexible. A lot of architecture types are bad - they're slower, inflexible, harder to read, harder to test. It works, but changing the color of an icon then takes 4 hours, and may possibly crash one of the screens.
There's also a lot of spaghetti code, god classes, people who hack things together until they work, instead of spending an hour reading the manual to find what the proper use is. For example, I've seen someone who wants to get location permissions install a whole map plugin and hide the map in the background, instead of just writing the code that requests location permissions.
I've got years of experience, and these days I'm spending an hour/day watching beginner programmer tutorials to unlearn a lot of the bad habits of the past.
None of the problems you speak of are language specific habits, they're just generally bad programming habits. And those bad habits aren't proof that writing code isn't the best way to learn. Of course, you can't just write bad code forever and expect to get better, you have to analyze your results or get feedback somehow and improve your programming. It's basically like every other skill.
Based on experience (40 years programming) were just as likely to learn good habits and practices as bad ones. Of course daily WTF things happen and we all make fun of them, but there’s no site like that to post when something goes right.
Programming is an ongoing learning process, and that means making mistakes and getting exposed to less than ideal solutions and habits along with the good ideas and practices. You can’t get either from tutorials or working on personal projects, because feedback and mentoring play a big part in making forward progress.
> How can I learn to play the guitar as fast as possible?
> How can I learn to submit jiu-jitsu black belts as fast as possible?
For some things in life shortcuts are simply not possible.
To get fluency you will have to: write a lot of code, read a lot of code, work on other people's code, have other people review your own code.
One thing that helps is already knowing a lot of other languages :). I usually duck-duck-go stuff like "$language for programmers" and "$language in 20 minutes" or "$language for people who know $similar_language" in order to find guides/howtos oriented a people who already know how to program. Because reading a Language guide that also teaches you what is an if statement or what is an exception is extremely boring to me.
There aren't any shortcuts.. But when I was in college we studied abroad and I learned way faster having to communicate than I would have in the US. So my advice would be to visit another country that speaks the language for an extended period of time.
13 comments
[ 2.8 ms ] story [ 44.7 ms ] threadI can usually read any C-family language without any study, because they are much more alike than different. I will need some reference material to fix bugs and make small changes. I may need a tutorial or a non-trivial code base to study to get to competency. Before I would lead a team or make expensive decisions I would want a couple of years experience with the language and ecosystem.
And you really hit the head on the nail with this one. Almost no company that we’ve worked with do things even remotely similar. Which is all right, if what they are doing works for them and produces stable products at a reasonable price and timeframe, then who really cares how they do it?
It does make for some interesting codebase transfers with modern public sector enterprise architecture though. Like when a major system goes from one IBM sized operator to another, because the winning bidder changed hands. But that’s another story, and it really just underlines what you say, because even huge international tech companies don’t remotely agree on practices.
Programmers who carry around the idea that they alone know how to write the first ever perfect piece of software, if only everyone would listen to them, cause more damage than the people cranking out working but imperfect code. The perfect is the enemy of the good, but we never seem to learn that.
I see this play out in my own work -- I specialize in legacy and abandoned applications. I'm often told by my customer that several developers looked at the code before me and declared it crap, unmaintainable, have to start over with (fad of the month) language. Yet the code works and has been maintained and enhanced for years or even decades (the opposite of unmaintainable). Ugly, yes. Requiring some commitment and study, yes. But not so terrible that starting over from scratch (which almost never works out as predicted) is a good business proposition. Call it hubris, call it fleecing unsophisticated customers, but this attitude just keeps software development reinventing the flat tire in different languages, to paraphrase Alan Kay.
One company I joined put all their database types as strings because it was most flexible. A lot of architecture types are bad - they're slower, inflexible, harder to read, harder to test. It works, but changing the color of an icon then takes 4 hours, and may possibly crash one of the screens.
There's also a lot of spaghetti code, god classes, people who hack things together until they work, instead of spending an hour reading the manual to find what the proper use is. For example, I've seen someone who wants to get location permissions install a whole map plugin and hide the map in the background, instead of just writing the code that requests location permissions.
I've got years of experience, and these days I'm spending an hour/day watching beginner programmer tutorials to unlearn a lot of the bad habits of the past.
Programming is an ongoing learning process, and that means making mistakes and getting exposed to less than ideal solutions and habits along with the good ideas and practices. You can’t get either from tutorials or working on personal projects, because feedback and mentoring play a big part in making forward progress.
> How can I learn to play the guitar as fast as possible?
> How can I learn to submit jiu-jitsu black belts as fast as possible?
For some things in life shortcuts are simply not possible.
To get fluency you will have to: write a lot of code, read a lot of code, work on other people's code, have other people review your own code.
One thing that helps is already knowing a lot of other languages :). I usually duck-duck-go stuff like "$language for programmers" and "$language in 20 minutes" or "$language for people who know $similar_language" in order to find guides/howtos oriented a people who already know how to program. Because reading a Language guide that also teaches you what is an if statement or what is an exception is extremely boring to me.