I've found the following really sets apart my programming now vs. earlier in my career:
1. I write and rewrite more now. I view the first time the code works as just the first draft (like I would with a paper). Earlier in my career I thought that making it work meant I was done.
2. I spend a lot more time thinking about what's happening in the code and why. I have found some of my best work to happen after days of thinking about small bits of functionality.
3. I get the domain (ie. the big picture) much better. This is insanely valuable and helps me step back.
4. I listen more to opposing views. That's not to say I don't argue my point, but afterwards I spend time to rehash what the other person said when I have no pressure to respond. This guides my thinking a lot as it give me an opportunity to change views/positions.
5. I'm increasingly tolerant of other technologies. I use x, but y must be good too b/c smart people use it.
5.a While I'm more tolerant, I'm less distracted. When I was younger, I spent more time switching technologies to learn "new things". Now I spend more time going deeper on my current stack to learn new things.
6. I now think its ok to write code in a "non optimal" way if it makes it easier for the entire team to work with. I don't believe in writing to the LCD, however I do believe programming just a little above the team's moving average capability is probably better than writing above everyone's head (whether by me or someone better than me).
I hate to sound like an old fogie here (I am almost 40) but one thing that occurs to me is that as we age our thinking changes and all the things you mention often develop over time.
When you are 20 you are pretty much at the height of your mathematical abilities. This is fine for certain kinds of programming, but it is not really ideal for others. It ensures that algorithms primary and the domains in a real sense become secondary. As you get older, these tend to flip. You understand the domains better and may not be quite as good at generating optimal algorithms, but the tradeoff is generally positive.
Additionally I think there is a tradeoff that happens between dreaming of building great things and developing a craftsmenship approach to the small things. Engineer the small pieces well, and the big pieces will take care of themselves.
In most areas, I think one is better with a very mixed-age and mixed-experience team. Older, more experienced programmers bring something very special to the table, but the same is true for younger programmers as well.
This being said, I have a few very minor disagreements with you ;-). These may be split hairs though.
First, while I rewrite more in some ways, I actually find on the whole I rewrite less because I am not afraid to procrastinate while trying to understand the domain. People wonder why my code seems to come out fully formed and it is because I am not afraid to spend my time thinking about the problem instead of writing a rough draft.
What has changed is the sort of rewrites I do. I will typically re-engineer a small piece to remove cruft based on lessons learned from the last two years, rather than rewriting a big piece to meet a new requirement (because things tend to be designed more extensably now). So I am less afraid to rewrite and more willing to do so, but at the same time, I tend to rewrite less.
Finally there is the question of optimal way to program. I am of the opinion (probably in part because of how much work I do with Perl) that there is no singular optimal way. Optimal has to be globally defined and one of the jobs of the engineer is to ensure that the framework is optimal so that the team can program optimally. If the team is not part of the definition of what is optimal, then I do agree it is a mess.
But I don't think we are dealing with a single dimension here. Understanding the problems the team is struggling with is a good way to ensure that framework can be built in a way that drives that average capability up.
> I'm increasingly tolerant of other technologies.
I would like to think I am, but recently I have noticed that everyone seems to want to jump on the NoSQL bandwagon. A lot of the jobs I see I would be a good fit want experience using MongoDB (or something similar).
I have been looking to learn them, but having read up on the technologies, I can't find a reasonable use case for any of them in my own work. One that would not be equally or better suited to Postgres or MySQL (which I know well).
I have come to the conclusion that 90% of people using NoSQL don't actually need it, and are throwing away a lot of useful features just so they can play with the latest fad.
This article did an excellent job verbalizing the incredible feeling of mental potency one gets when learning to program. When you see that first "Hello, World!", you are hooked. I still get this feeling whenever I learn a new platform. When I learned Android I was amazed that I had made a real-life app run on my phone. When I learned Ruby on Rails I proudly stuck my flag in the surface of the internet and declared myself ruler of my domain (pun intentded). When I learned to program an Arduino I felt my code-laden tendrils inching out into the real world: that light is blinking because I demanded it do so!
This is why i'd like to teach programming to kids. I really don't care if they continue with it or ever learn how to do anything useful, I just want to expose everyone to that feeling of power you can get when you're behind a keyboard and in front of the right tools. It makes you think you can do something amazing, and everyone should have a chance to feel that.
The desire to empower kids is basically one of the best motivations available to everyone. I'd recommend poking around for after school programs where you can volunteer to do it. I spent a month or two teaching HTML to a small group of middle schoolers and it was easily one of my favorite experiences in life.
For me the thing I had to learn was commenting more than anything else; working alone I never saw as much use for it. Then I worked with a guy that commented his code very well and suddenly I saw massive value in it.
I'm definitely still an intermediate programmer, but I think I was always fine admitting that to myself. It was getting over the fear of others reading and modifying my code that took me a while.
The big thing I learned (at a company where all changes are code reviewed) is to rewrite the code until it seems obviously correct to someone who doesn't know what I know. I rename variables, methods and extract code into small methods until someone can read the code out loud and it sounds like a comment.
for example:
if (!thereIsEnoughSpace(user.getDataRequestSize()) {
if (canAllocateAdditionalStorage()) {
reserveStorageForUser(user, user.getDataRequestSize());
...
I've found many bugs after I renamed variables like 'i', 'j', 'k', etc to something more meaningful. That made it easier to realized I was using them incorrectly.
This is basically why I think I'm an ok developer...
I pretend to be the smartest developer in my group (let's call him Bob). I look at a line of code and ask myself, why will Bob ask me the change this line of code? What will he prevent me from checking in? How would he solve this problem?
I do this even if I have a really difficult problem and Bob is the "go to" person. I pretend to be Bob and ask myself, What question will Bob ask me when I tell him about the problem? He will ask me if I've searched google, ok I will search first. He will ask me if I've checked for an upgrade to a library, I will do that. He will ask if I've set a break point here and checked for a memory corruption there. etc. 80% of the time, I find the problem myself and the rest of the time, Bob doesn't know the answer either. But at the end of the day co-workers are fooled into thinking that I'm as good as he is. But I have no doubt that Bob is better because it is important to him to learn everything he can about some key technology. I only approximate Bob when I need to interact with others. If you ask Bob a question, you get a quick and correct response. If you ask me, I will tell you I'm in the middle of something else and I will get back to you in a few minutes but really I have to figure out the answer first hahaha. I try my best to avoid getting help from Bob because, honestly, I don't think Bob respects people who aren't as passionate as he is (most people confuse passion with intelligence). The downside, is that it takes me a day to solve a problem that Bob can solve in a few minutes. Managers hate that but it is just too boring to learn technology to the degree that Bob knows it in my free time.
I totally agree. When I first started programming my comments largely echo'd the code, so I saw them as less valuable. Now I'm able to stand back from the code and write comments that reflect the "why", and let the code do the talking for the "what / how".
I see this a lot where the more experienced someone is the more they comment, but also where the comments are higher quality.
It's good you recognized that. In many cases, an intermediate programmer with expert-level group skills (including things like commenting) is worth much more than an advanced programmer with poor group skills. But often people neglect their group skills; they aren't "sexy".
I had the opposite experience; I found it easy to scan through comments explaining what the code does, and hard to read the code itself. So I would comment every single thing to explain it in English so that I didn't have to resort to code. Of course I could drop into code mode and rely on logical axioms and learned patterns, but it wasn't as intellectually satisfying as "getting it" with pure intuition.
Something similar still serves me well as a general mental framework for approaching programming and debugging at a very local (procedure) level:
1. Make sure that the English language description of the algorithm is logically correct.
2. Make sure the code actually corresponds to the English description.
I randomly met a guy who told me of his idea to implement a UX framework with windows, buttons, views, etc in python.
A week later he sends me the finished framework. And it's perfect. It's easy to understand, all the names of things make sense, it's orthogonal. Not a single comment anywhere, but perfectly clear. Great code basically.
And there's a project I am maintaining where some parts of the code are pretty much impossible to understand, full of duplicated code - somebody loved copy&paste - duplicated method and class names, and threads going off in all directions. There is a comment for every line of code but despite the fact that I consider myself pretty good at reading other people's code, I am not touching that thing with a 10 foot pole.
My goal is to write code that doesn't require a lot of comments.
It depends on the people working with you, sometimes I feel commenting should be left for edge cases only. More often than not it seemed that people read the comments and stop focusing when reading the code; they just check if it vaguely matches the comments. When foregoing comments entirely there was much better feedbacks and questions on important points, the understandig of the code base seemed much better.
The latter also forces you to keep a very clean code, and tricky parts (things you couldn't simplify nor make self explanatory) surface better.
From both my own experience and witnessing others, one major factor that sets apart from beginner and expert is working with legacy code. And by legacy I mean legacy from previous developer, previous team, whatever, not necessarily a decade old code base.
Beginners are keen to get rid of all the legacy code. It's tightly coupled, it's hard to read, hard to maintain, yada yada yada. And then they tend to make a way too optimistic estimate on how long it will take. While it might look like nothing fancy from outside, under the hood it often handles loads of edge cases etc. Been there, almost done that (didn't fit in the budget which was way too optimistic already). Eh.
Experienced programmers understand that it's not perfect, but they just live with that. Surely there are some cases when maintaining the codebase would be waste of money because the previous coder was a disaster, and sooner or later it will have to be scrapped away. But it's more tempting to do that than actually needed.
I had a nightmare of VB6 code to work on. Something like 3/4 of a million lines, and lots of deadlines to meet. No consideration given to quality - just have it working by friday. It was in the financial industry.
On more than one occasion you would write a subroutine to do something, then a month or two later, you would see someone had already written that same functionality.
Also I'd argue one shouldn't be considered an expert programmer until they've been forced to maintain lots of legacy code. It's an incredible lesson in what not to do, knowing when to comment and when not, proper naming, which things to optimize "prematurely" based on your experience-based predictions of how your application will scale, how to organize code in support of a growing codebase, etc.
AFAIK this is actually normal -- you learn the basics from tutorials, then the things that you need to make more complicated projects easier seem unnecessary, then you attempt a large project without them, and then you see why they're necessary.
It's normal but can be really, really scary if you don't have a mentor or someone to help you out or point out some of the pitfalls on the way.
Even something as fundamental as version control is, I think, passed up by a lot of beginning/intermediate programmers because "it's complicated" and "I don't need it now because I'm the only one working on this." But a mentor can help push you into that earlier and walk you through some of the more common stuff in a more accessible, interactive way than an article or a forum, which goes a long way.
I've actually been down this route when I was a kid experimenting with making programs. I did not understand what was the point of functions - why not just copy/paste blocks of logic?
It wasn't something important to me for a long time since I did other stuff instead, but coming back to programming in an effort to make a career out of it, a lot of that stuff became instantly obvious & I felt foolish for not recognizing it in the first place.
> It wasn't something important to me for a long time since I did other stuff instead, but coming back to programming in an effort to make a career out of it, a lot of that stuff became instantly obvious & I felt foolish for not recognizing it in the first place.
I think one of the key things experienced programmers finally get is that we never stop understanding that there are things which we are doing sub-optimally and can continue to be reflective and self-critical of that. How can I structure my code better? How can I solve this software development problem that seems to come up frequently?
And then as we solve them, the solutions seem so obvious we wonder why we didn't realize it sooner.
It's funny, as a kid I can remember thinking: "Right, everything has to go in the main function unless absolutely necessary, it will just be easier to read that way."
There are some absolute, rather than relative measures that you can use to gauge your skill. For engineering fields (not just software) the 'toolmaker' analogy is a good one i find. Until you understand what involved in making the specialist tools you need for your field, and can actually make those tools yourself then you are far from mastery.
This is not entirely straightforward though - a bit of a rabbit hole you could say. e.g. should a programmer stop at the compiler? The CPU? The circuitry? Electronic components? The laws of nature? Tools are built with other tools after all and some tools are provided by nature...
On the other hand, if you haven't made even the first step towards understanding your tools then thats not really a problem to worry about.
I found this so striking in part because of recent events: Mark Karpeles's mother defending him as a genius, Karpeles not delegating coding to experienced developers and focusing on being a CEO, the leaked PHP MtGox code...
I find his experience is very fulfilling. In the beginning he had fun times doing stuff which actually delivered some results. Probably gradually became aware of wrong chooses he made and discovered architect side of coding... I kinda feel this is a way to learn it. I think you need this excitement of fast moving to keep engaged - it is hacker part of coding. When you are young it is okey to try something, may be break something and move on.
... Or may be I think like that only because I can see myself almost in every single line author posted :)
I agree with the other commenters here. This is part of your development. Yes, it could've possibly be avoided if you had a CS background or worked alongside other developers. But it's normal.
When I was still in high school I "invented" inheritance in PHP. I put one function per file, and used the include search path. When I discovered OO later I realized what I had done.
1. Read more books. Turn off Twitter, FB, whatever, and open your Kindle app. But be picky. Don't read crap.
2. Read every day. 30 minutes minimum at the same time every day.
3. Write code that implements what you learn.
4. Write code that is more consistent. Learn to write in patterns. Use patterns that you both learn from a.) books, b.) reading other people's code, and c.) that you come up with on your own.
5. Program by using coding standards. Either your own, or if you're in a company then follow the team's standards.
6. Review what you've written. Identify alternatives to the patterns you've used. How else can feature x be implemented? What do you like about each approach? What do the experts say about each approach. Then read everything you can about various approaches to a given problem and implement as many of them as you have time for.
7. Read some code written by someone way beyond your skill level in a language you know. Take in how well they write. Pick one thing they did well, read about it, understand it, then integrate it into your coding.
8. Rewrite something you wrote at least a year ago. Can you easily find a better way to implement this code? If yes, then rewrite. If not, then read more.
9. Learn one new tool that helps improve your workflow and get to a point of daily use.
10. Speed up. Use automation to eliminate the basic coding that you already know well and that is now wasting your time. Use whatever is easy for you whether its templates, macros, boilerplate, generators or automation. Just pick one and automate away the stuff you've already learned.
My recommendation is to tackle ambitious projects as an open source programmer. Do things well beyond your comfort zone and expect to fail.
The fact is that you won't get better unless you actually fail and are introspective enough both to realize you did (there are programmers out there who never realize this and I have tried, unsuccessfully, to work with them). So pick something you aren't sure you can succeed at.
The second thing is to be evaluating your development challenges as you go, be introspective, and learn from them. Every development challenge is an opportunity to get better.
The third thing to do is to start reading about cracking software and start working on cracking your own software. If you can get others to crack your software, better yet. You will learn a lot about best practices from this.
The fourth thing to do is to try to work with teams of open source developers and learn from others. I have never learned anything from someone who always agreed with me, and a friend of mine is fond of saying, if a village has two wise men who always agree on everything, the village has one more wise man than it needs.
Read more code. Edit code others have written. Maintain a wide variety of projects. Try to start your own.
Failure can be tough and sneaky: I didn't want to fail, so I Googled to see how others did it until I was sure... Then found I couldn't reach a consensus, and ended up "researching" for months. Sometimes doing it wrong isn't failing, after all, you've just found a way that didn't work-- that's progress.
Oh and reading or knowing how to do it isn't doing it. There can be quite a bit of work to doing it yourself, don't skip the exercises at the end of the metaphorical chapter ;-)
I have been working on my own code base for the last 3 years. It is constantly evolving, and requirements constantly change. I often have to revisit a piece of code I worked on 6 months ago. That is the best time to tell. If your own code doesn't make sense to you fairly quickly, it is worth refactoring. Look it and ask yourself why it is difficult to understand and what you could do to make it better.
I've worked on enterprise software and people in the company thought of me as one of the better programmers there, but when I do open-source stuff I feel like an imbecile.
I quit my job and wanted to learn and get better, but I don't know how to start.
Defense, defense, defense. Your code should be peppered with checks that should never go wrong. You should feel stupid writing them.
They will save you a lot of headache one day.
Really the only way to get better is to write stuff and ship it to someone who uses it, and you have to experience the pain of supporting it. That's when all the important lessons are learned.
Nice article but i was wondering why didn't you go to university/IT School to learn computer science?
--
"To me, the object-oriented approach was just a bunch of unnecessary overhead and boilerplate"
If you had made real C++, you would'nt have think of object oriented programming as an overhead. I suggest you to buy a few O'Reilly books (Probably the best code book )
Not the author, but personally, I chose Maths as I felt it gave me a broader basis to approach my career. I am now happily employed as a Software Engineer. I do find I've missed out on some things (TDD indoctrination, for example), but I've gained in others.
Although I generally do not post something that is not constructive to an article, I have to say, I bought the same magazine when I was younger with Borland on and that is what made me want to become a programmer!
I was amazed when I read that point. The only difference is that I couldn't get anything to build in Borland. I started out in BASIC making my motherboard beep to tunes in a BAT file.
Code Complete is really great. I also recommend Clean Code. I started reading it before going to sleep, and it got me so excited I couldn't sleep. It was 4 or 5am when I finished it. All I could think about was refactoring all the code I had ever written.
You have to stop thinking about what's good about your work and focus instead on what sucks about it. Sounds depressing maybe, but that's how you get better. You can feel good about yourself, or you can get better.
[+] [-] akbar501|12 years ago|reply
1. I write and rewrite more now. I view the first time the code works as just the first draft (like I would with a paper). Earlier in my career I thought that making it work meant I was done.
2. I spend a lot more time thinking about what's happening in the code and why. I have found some of my best work to happen after days of thinking about small bits of functionality.
3. I get the domain (ie. the big picture) much better. This is insanely valuable and helps me step back.
4. I listen more to opposing views. That's not to say I don't argue my point, but afterwards I spend time to rehash what the other person said when I have no pressure to respond. This guides my thinking a lot as it give me an opportunity to change views/positions.
5. I'm increasingly tolerant of other technologies. I use x, but y must be good too b/c smart people use it.
5.a While I'm more tolerant, I'm less distracted. When I was younger, I spent more time switching technologies to learn "new things". Now I spend more time going deeper on my current stack to learn new things.
6. I now think its ok to write code in a "non optimal" way if it makes it easier for the entire team to work with. I don't believe in writing to the LCD, however I do believe programming just a little above the team's moving average capability is probably better than writing above everyone's head (whether by me or someone better than me).
[+] [-] einhverfr|12 years ago|reply
When you are 20 you are pretty much at the height of your mathematical abilities. This is fine for certain kinds of programming, but it is not really ideal for others. It ensures that algorithms primary and the domains in a real sense become secondary. As you get older, these tend to flip. You understand the domains better and may not be quite as good at generating optimal algorithms, but the tradeoff is generally positive.
Additionally I think there is a tradeoff that happens between dreaming of building great things and developing a craftsmenship approach to the small things. Engineer the small pieces well, and the big pieces will take care of themselves.
In most areas, I think one is better with a very mixed-age and mixed-experience team. Older, more experienced programmers bring something very special to the table, but the same is true for younger programmers as well.
This being said, I have a few very minor disagreements with you ;-). These may be split hairs though.
First, while I rewrite more in some ways, I actually find on the whole I rewrite less because I am not afraid to procrastinate while trying to understand the domain. People wonder why my code seems to come out fully formed and it is because I am not afraid to spend my time thinking about the problem instead of writing a rough draft.
What has changed is the sort of rewrites I do. I will typically re-engineer a small piece to remove cruft based on lessons learned from the last two years, rather than rewriting a big piece to meet a new requirement (because things tend to be designed more extensably now). So I am less afraid to rewrite and more willing to do so, but at the same time, I tend to rewrite less.
Finally there is the question of optimal way to program. I am of the opinion (probably in part because of how much work I do with Perl) that there is no singular optimal way. Optimal has to be globally defined and one of the jobs of the engineer is to ensure that the framework is optimal so that the team can program optimally. If the team is not part of the definition of what is optimal, then I do agree it is a mess.
But I don't think we are dealing with a single dimension here. Understanding the problems the team is struggling with is a good way to ensure that framework can be built in a way that drives that average capability up.
[+] [-] collyw|12 years ago|reply
I would like to think I am, but recently I have noticed that everyone seems to want to jump on the NoSQL bandwagon. A lot of the jobs I see I would be a good fit want experience using MongoDB (or something similar).
I have been looking to learn them, but having read up on the technologies, I can't find a reasonable use case for any of them in my own work. One that would not be equally or better suited to Postgres or MySQL (which I know well).
I have come to the conclusion that 90% of people using NoSQL don't actually need it, and are throwing away a lot of useful features just so they can play with the latest fad.
[+] [-] habosa|12 years ago|reply
This is why i'd like to teach programming to kids. I really don't care if they continue with it or ever learn how to do anything useful, I just want to expose everyone to that feeling of power you can get when you're behind a keyboard and in front of the right tools. It makes you think you can do something amazing, and everyone should have a chance to feel that.
[+] [-] saraid216|12 years ago|reply
[+] [-] tbomb|12 years ago|reply
[+] [-] ameister14|12 years ago|reply
I'm definitely still an intermediate programmer, but I think I was always fine admitting that to myself. It was getting over the fear of others reading and modifying my code that took me a while.
[+] [-] swframe|12 years ago|reply
I've found many bugs after I renamed variables like 'i', 'j', 'k', etc to something more meaningful. That made it easier to realized I was using them incorrectly.
This is basically why I think I'm an ok developer...
I pretend to be the smartest developer in my group (let's call him Bob). I look at a line of code and ask myself, why will Bob ask me the change this line of code? What will he prevent me from checking in? How would he solve this problem?
I do this even if I have a really difficult problem and Bob is the "go to" person. I pretend to be Bob and ask myself, What question will Bob ask me when I tell him about the problem? He will ask me if I've searched google, ok I will search first. He will ask me if I've checked for an upgrade to a library, I will do that. He will ask if I've set a break point here and checked for a memory corruption there. etc. 80% of the time, I find the problem myself and the rest of the time, Bob doesn't know the answer either. But at the end of the day co-workers are fooled into thinking that I'm as good as he is. But I have no doubt that Bob is better because it is important to him to learn everything he can about some key technology. I only approximate Bob when I need to interact with others. If you ask Bob a question, you get a quick and correct response. If you ask me, I will tell you I'm in the middle of something else and I will get back to you in a few minutes but really I have to figure out the answer first hahaha. I try my best to avoid getting help from Bob because, honestly, I don't think Bob respects people who aren't as passionate as he is (most people confuse passion with intelligence). The downside, is that it takes me a day to solve a problem that Bob can solve in a few minutes. Managers hate that but it is just too boring to learn technology to the degree that Bob knows it in my free time.
[+] [-] akbar501|12 years ago|reply
I see this a lot where the more experienced someone is the more they comment, but also where the comments are higher quality.
[+] [-] sliverstorm|12 years ago|reply
[+] [-] brianpgordon|12 years ago|reply
Something similar still serves me well as a general mental framework for approaching programming and debugging at a very local (procedure) level:
1. Make sure that the English language description of the algorithm is logically correct.
2. Make sure the code actually corresponds to the English description.
[+] [-] nikster|12 years ago|reply
Great code needs no comments.
Bad code needs lots of comments.
I've seen examples of both recently.
I randomly met a guy who told me of his idea to implement a UX framework with windows, buttons, views, etc in python.
A week later he sends me the finished framework. And it's perfect. It's easy to understand, all the names of things make sense, it's orthogonal. Not a single comment anywhere, but perfectly clear. Great code basically.
And there's a project I am maintaining where some parts of the code are pretty much impossible to understand, full of duplicated code - somebody loved copy&paste - duplicated method and class names, and threads going off in all directions. There is a comment for every line of code but despite the fact that I consider myself pretty good at reading other people's code, I am not touching that thing with a 10 foot pole.
My goal is to write code that doesn't require a lot of comments.
[+] [-] hrktb|12 years ago|reply
The latter also forces you to keep a very clean code, and tricky parts (things you couldn't simplify nor make self explanatory) surface better.
[+] [-] gedrap|12 years ago|reply
Beginners are keen to get rid of all the legacy code. It's tightly coupled, it's hard to read, hard to maintain, yada yada yada. And then they tend to make a way too optimistic estimate on how long it will take. While it might look like nothing fancy from outside, under the hood it often handles loads of edge cases etc. Been there, almost done that (didn't fit in the budget which was way too optimistic already). Eh.
Experienced programmers understand that it's not perfect, but they just live with that. Surely there are some cases when maintaining the codebase would be waste of money because the previous coder was a disaster, and sooner or later it will have to be scrapped away. But it's more tempting to do that than actually needed.
[+] [-] collyw|12 years ago|reply
On more than one occasion you would write a subroutine to do something, then a month or two later, you would see someone had already written that same functionality.
[+] [-] nollidge|12 years ago|reply
[+] [-] nikster|12 years ago|reply
We once tried to contract this really fancy team to take over some code. They asked if we had unit tests. "No". "Then we can't do it, sorry, bye."
And I agree with them.
[+] [-] gregimba|12 years ago|reply
[+] [-] csense|12 years ago|reply
[+] [-] sdrothrock|12 years ago|reply
Even something as fundamental as version control is, I think, passed up by a lot of beginning/intermediate programmers because "it's complicated" and "I don't need it now because I'm the only one working on this." But a mentor can help push you into that earlier and walk you through some of the more common stuff in a more accessible, interactive way than an article or a forum, which goes a long way.
[+] [-] lugg|12 years ago|reply
[+] [-] Bahamut|12 years ago|reply
It wasn't something important to me for a long time since I did other stuff instead, but coming back to programming in an effort to make a career out of it, a lot of that stuff became instantly obvious & I felt foolish for not recognizing it in the first place.
[+] [-] einhverfr|12 years ago|reply
I think one of the key things experienced programmers finally get is that we never stop understanding that there are things which we are doing sub-optimally and can continue to be reflective and self-critical of that. How can I structure my code better? How can I solve this software development problem that seems to come up frequently?
And then as we solve them, the solutions seem so obvious we wonder why we didn't realize it sooner.
[+] [-] poopicus|12 years ago|reply
Nowadays, it's the exact opposite!
[+] [-] runiq|12 years ago|reply
[+] [-] jheriko|12 years ago|reply
This is not entirely straightforward though - a bit of a rabbit hole you could say. e.g. should a programmer stop at the compiler? The CPU? The circuitry? Electronic components? The laws of nature? Tools are built with other tools after all and some tools are provided by nature...
On the other hand, if you haven't made even the first step towards understanding your tools then thats not really a problem to worry about.
[+] [-] gwern|12 years ago|reply
[+] [-] encoderer|12 years ago|reply
Now, I wouldn't necessarily use PHP for this sort of work, but...
[+] [-] hippich|12 years ago|reply
... Or may be I think like that only because I can see myself almost in every single line author posted :)
[+] [-] encoderer|12 years ago|reply
When I was still in high school I "invented" inheritance in PHP. I put one function per file, and used the include search path. When I discovered OO later I realized what I had done.
It happens :)
[+] [-] ritchiea|12 years ago|reply
[+] [-] akbar501|12 years ago|reply
1. Read more books. Turn off Twitter, FB, whatever, and open your Kindle app. But be picky. Don't read crap.
2. Read every day. 30 minutes minimum at the same time every day.
3. Write code that implements what you learn.
4. Write code that is more consistent. Learn to write in patterns. Use patterns that you both learn from a.) books, b.) reading other people's code, and c.) that you come up with on your own.
5. Program by using coding standards. Either your own, or if you're in a company then follow the team's standards.
6. Review what you've written. Identify alternatives to the patterns you've used. How else can feature x be implemented? What do you like about each approach? What do the experts say about each approach. Then read everything you can about various approaches to a given problem and implement as many of them as you have time for.
7. Read some code written by someone way beyond your skill level in a language you know. Take in how well they write. Pick one thing they did well, read about it, understand it, then integrate it into your coding.
8. Rewrite something you wrote at least a year ago. Can you easily find a better way to implement this code? If yes, then rewrite. If not, then read more.
9. Learn one new tool that helps improve your workflow and get to a point of daily use.
10. Speed up. Use automation to eliminate the basic coding that you already know well and that is now wasting your time. Use whatever is easy for you whether its templates, macros, boilerplate, generators or automation. Just pick one and automate away the stuff you've already learned.
Repeat.
[+] [-] einhverfr|12 years ago|reply
The fact is that you won't get better unless you actually fail and are introspective enough both to realize you did (there are programmers out there who never realize this and I have tried, unsuccessfully, to work with them). So pick something you aren't sure you can succeed at.
The second thing is to be evaluating your development challenges as you go, be introspective, and learn from them. Every development challenge is an opportunity to get better.
The third thing to do is to start reading about cracking software and start working on cracking your own software. If you can get others to crack your software, better yet. You will learn a lot about best practices from this.
The fourth thing to do is to try to work with teams of open source developers and learn from others. I have never learned anything from someone who always agreed with me, and a friend of mine is fond of saying, if a village has two wise men who always agree on everything, the village has one more wise man than it needs.
[+] [-] lstamour|12 years ago|reply
Failure can be tough and sneaky: I didn't want to fail, so I Googled to see how others did it until I was sure... Then found I couldn't reach a consensus, and ended up "researching" for months. Sometimes doing it wrong isn't failing, after all, you've just found a way that didn't work-- that's progress.
Oh and reading or knowing how to do it isn't doing it. There can be quite a bit of work to doing it yourself, don't skip the exercises at the end of the metaphorical chapter ;-)
[+] [-] collyw|12 years ago|reply
[+] [-] k__|12 years ago|reply
I've worked on enterprise software and people in the company thought of me as one of the better programmers there, but when I do open-source stuff I feel like an imbecile.
I quit my job and wanted to learn and get better, but I don't know how to start.
[+] [-] brc|12 years ago|reply
They will save you a lot of headache one day.
Really the only way to get better is to write stuff and ship it to someone who uses it, and you have to experience the pain of supporting it. That's when all the important lessons are learned.
[+] [-] joeld42|12 years ago|reply
[+] [-] erazor42|12 years ago|reply
--
"To me, the object-oriented approach was just a bunch of unnecessary overhead and boilerplate"
If you had made real C++, you would'nt have think of object oriented programming as an overhead. I suggest you to buy a few O'Reilly books (Probably the best code book )
[+] [-] alexchamberlain|12 years ago|reply
[+] [-] justplay|12 years ago|reply
http://webcache.googleusercontent.com/search?q=cache%3Awww.m...
[+] [-] chrislomax|12 years ago|reply
I was amazed when I read that point. The only difference is that I couldn't get anything to build in Borland. I started out in BASIC making my motherboard beep to tunes in a BAT file.
[+] [-] nollidge|12 years ago|reply
[+] [-] V-2|12 years ago|reply
[+] [-] dsego|12 years ago|reply
[+] [-] badman_ting|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]