Confessions of an Intermediate Programmer
michaelbromley.co.uk
michaelbromley.co.uk
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).
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.
Is that really true?
There are many examples of people who came to mathematics late in life and did good things:
http://mathoverflow.net/questions/3591/mathematicians-who-we...
I think you only get better with time if you keep yourself sharp. What has changed for me is that I can't sit still and pound back Redbulls for six-hour coding sessions and then hit the gym. My process is also more methodical.
But mathematics is certainly one area I've only improved in with time.
However, I wonder if there is something else going on here. What I noticed in the list (and in the article I am linking to) is that the early peak seems less obvious from a historiography perspective than it does from a contemporary perspective. So I can't help but wonder if there is a qualitative difference in the sorts of contributions that younger and older mathematicians make.
Thinking more in terms of fluid vs crystalized intelligence here, but wondering if there is something else. I know my fluid intelligence is not where it was ten years ago, but part of that is a greater understanding of the problem domain. I can see more possibilities, and I see different ones than I would have before.
So I don't think it is as simple as we might want to think but I do think that thinking patterns (and abilities) change qualitatively as we age in ways which are favorable for important contributions when viewed through the light of history. Whether a thesis review board would agree is a different matter.
It's almost certainly not true, at least among those that would be called mathematicians. This follows if for no other reason than the fact that it takes years to get up to speed with the forefront of any particular branch of mathematics, which is the prerequisite for testing out one's mathematical abilities (in the context of research). While you occasionally have a few teenage prodigies, most mathematicians won't get started on their career until much later.
Computer science courses usually teach something very different from every day programming. You learn linear algebra, AI, dynamic programming.
Then you go to work and spend 10 years mostly not doing those things. They are generic, and there are libraries for generic things - you just need to understand how they behave.
A decade later, most people will only retain the specific techniques they use in their domain. Maybe you know more than you ever did about indexing algorithms, but the math behind the deep learning algorithm you wrote at college is gone.
Guess and check programming tends to optimize around fast reset cycles so that many, many solutions can each be tried with little investment. This is the programmer who loves to refresh their window every second to see how their changes impacted the product. It's high energy and exciting. It also lends itself to prepackaged solutions—be they existing frameworks of specific transliterations of known algorithms. I also find that it tends to generate spaghetti code more quickly (all styles do, but GnC does so more quickly) and to fall flat on tasks which have either slow reset cycles, long dependency chains, or are difficult to visualize.
"Slow" programming, for the lack of a better word, orients itself around a deep understanding of both the domain and the natural "seams" in the problem space. It involves a lot of quick drafts that are perhaps never even observed—the mere act of trying and failing to express the problem elegantly is highly informative. It tends to find less "obviously optimal" solutions because it's in search of novel optimal solutions. It also tends to be more easily guided by high-level goals such as business value or elegance. Finally, programming slowly requires great reasoning skills and thus is more amenable to tools and processes which enhance reasoning. It can take stabs at deep, difficult domains because it happily uses great domain modeling or mathematical skills to break those challenging domains into clever, interlocking, and simple pieces. For all this though it suffers from having a design aesthetic and becomes less willing to "just dive in there and try all 500 solutions" in case one of them works.
I think this cuts broadly across several stylistic differences in coders. I think that age and experience pushes one toward the latter style. I also think that they both have strengths and weaknesses—so I strongly agree that mixed style teams are valuable.
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.
I'm a pretty 'young' person, and a much younger programmer, so I can't quite say I got the 'oo shiny lemme use that' thing out of my system, but I'm okay with that (for now it doesn't negatively impact my work, and I learn tons of stuff). But in other areas of life, I've noticed that I generally become less dichotomous in my approach to new and other things, but more discerning too.
I used to have a presentation from Facebook where they spoke about their zero-downtime migration process, but I can't find it, so this SO post [2] will do. Of course, there's a bunch more information out there to read up on.
[1] https://www.honeybadger.io/blog/2013/08/06/zero-downtime-mig...
[2] http://stackoverflow.com/questions/6740856/how-do-big-compan...
That said, I think you're right that 90% of the time SQL is a better solution. You don't fully realize all the great stuff a real SQL engine does for you until you have to go without it.
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.
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.
I see this a lot where the more experienced someone is the more they comment, but also where the comments are higher quality.
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.
1. An english language description of what the function (or code block) does as a black box (forget the internals as they are subject to change). What you put in and what you get out, or section headings to structure how you read the code.
2. Comments in the code block to tell you why a given decision was made.
What this gives you is the framework you are describing but it further cements it into three layers:
1. Function and block documentation describe contract and what the code is expected to do from outside. If the code does not implement the contract the code is wrong.
2. When reading through the code as contract-implementation you can understand why certain decisions were made.
As bonus points, you get good API documentation.
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.
Another couple of ways to improve your coding...
Start with comments outlining what you're going to do. If you are pair programming, this shows the other person what your overall plan is. It also acts as a mini todo list. They should be "What comments". That is, what does this piece of code do, not how it should be done. Comments are better than just coding because you can do that quickly as a sketch to show your partner. Then they don't just sit there waiting for you to type out a lot of the algorithm.
You can also start doing this with tests first, which help you outline the interface for your object/method/function/module. This also helps you think about how easy your piece of code is to use by users of your code. ALotOf. ProgrammersDoNotThinkHowEasyYourFunctionIsToCall(x,a,3). Is it obvious what it does, and what the required arguments are for the caller? Is error handling sane for the caller?
Coding considering Revision control is very important, and these days acts like great documentation. With tools like git blame, you can see comments for pieces of code inside the revision control system. If you limit commits to nice small chunks on one topic at a time this is very helpful for people. Don't include white space fixes with 5 days of changes to 30 files at once, with a comment like "update". If they are nicely explained by the revision control comments, and perhaps even reference your issue tracker, then other people reviewing, reading, or bug fixing your code later will have a much easier time.
Finally, know when you are in prototype mode, pitch/demo mode, quick script mode, or Serious engineering mode. Each call for different approaches, and have different requirements. Don't let the Serious engineer get you to do a 10 day development cycle when you have a time limit of 1 day to deliver. That's a fail. Also, it's a fail if you hack something up without following all the development guidelines for some embedded life critical piece of software.
Generally I think comments are bad and it's too easy to leave nonsense in the code with that technique.
Having to explain to another what you're doing - I found that to be great as well. It removes bugs and produces cleaner code. You don't even need another - at check-in time, for every change, you can ask yourself "what is this doing" and "why". And if the answer isn't convincing, change what you're doing.
The value of peer-review was rarely on the peer's side - the other person doesn't really know what you're doing and is unlikely to catch a bug. But the peer would ask some question so you would start thinking about it and discover a problem.
The best thing about asking somebody for advice is often to come up with a good question. If you ask the right question, it contains the answer.
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.
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.
Sure it does.
« The simple and obvious way to do this misses important edge cases X, Y and Z. »
« This is to work around a bug in the framework we're using; see http://... . »
« This is deliberately wrong, for compatibility with ABC system. »
Great code implementing a particular algorithm for a particular reason might want a comment (1) identifying the algorithm and providing a reference to a published description, and (2) identifying the reason the algorithm was chosen.
Great code that is clear and readable and well-fit to purpose can still, very often, benefit from comments. Not everything that might want to be made clear to readers of code can be expressed in the code.
I can't be certain about your first example, but writing a UX framework is a pretty straightforward thing in terms of what it needs to do, so there probably wouldn't be much need to comment about what it's doing. Why, though - that's a whole 'nother question. Surely it's missing some of those whys.
> Great code needs no comments.
I think declaring intent is the most valuable comment. What was the author going for with this function? Why is there a nil-guard here when the database column is `NOT NULL`? Is there an actual edge-case or is our data bad or was the author just being arbitrarily defensive against a boogeyman nil?
When reading other people's code, I've found that most of my time is spent figuring out not what the code does, but rather the author's goals and their higher level game plan.
I agree with other commentators that with comments one can at least express the intent and reasons for particular decisions.
And on a side note, it's wonderful to strive to write great code, but I believe it's easy to misjudge and think "Oh, I clearly write understandable code, thus I'll skip comments" even when it's not that clear. That certainly has happened to me, very likely to others at some point as well.
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.
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.
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.
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.
A lot of room for disruption there I think if someone works out how to make version control fit better with ordinary people's view of the world (i.e. not git, svn etc). Versions in word are the closest I've seen to it but it really shouldn't be in one specific program but in the OS or a helper program.
Things like File History and Time Machine are nice, but don't really address this need.
"When you have a ham^H^H^HVCS, everything looks like a programming project".
I ask this as someone somewhere between "beginner" and "intermediate". I've used git on a bunch of projects, but normally get hung up with branches or with trying to undo changes. Even harder than version control, I think, is getting a lone beginner programmer to write tests. When I'm writing something, it's always tricky figuring out exactly what it is I should be testing. When time is a limiting factor, it's hard to get from "I know I should be doing this" to actually doing this.
When you are good enough to make your own projects work the way you want them to work, but not good enough to contribute to the open source projects you actually use, how do you break out of your bad habits that you know you will need to break when part of a team/large project?
If you don't have time to write tests then you've overscoped the features for the available time. Once you start treating testing as essential and budgeting a realistic amount of time to write test code (probably on the order of 1:1 feature code time:test code time) then you'll be able to get it done. Your total number of features will go down but quality will go up.
Sorry, that was a long way of pointing out that us novice programmers often don't have good methods of determining how long something should take because we've never done it before.
That is basically the core difficulty in software estimation: none of us have good methods for determining how long something should take because most of the time we haven't done it before. If it had been done before in a way we can reuse, we'd reuse it. The meat of most projects is always something that's in some way new, even when the new bit is integrating a bunch of pre-existing parts in a new way.
But there is no one true code to test ratio. If you're trying to become a better programmer be wary of dogma.
As posted here the other day, airbnb didn't have much testing until a year ago: http://nerds.airbnb.com/testing-at-airbnb/
I'm not saying either way is right or wrong, which is kind of my point.
You already have a hard problem on your hands, figuring out how to get something to work normally in this new environment. Don't compound that right off the bat by trying to learn a new testing system too. In addition, reality is the ultimate test. By getting it working normally first, you know that it actually works, so if you write a test against it, and the test fails, then the test is probably wrong.
Once you get good with it, you should be able to reverse it and go to a more TDD-like workflow - write tests and code first, then manually test, and have confidence that if the tests work, then the app will work for the users too.
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.
Nowadays, it's the exact opposite!
I've mostly worked with higher level languages, and recently delved back into C. I had forgotten what a complete pain in the ass it is to pass complex data structures around between functions.
I'm a bit ashamed to admit my functions got pretty damn beefy real quick.
AFAIK, that's only a legal function signature in C++.
To the point of the question : when I wrote that, I was specifically thinking of 2-dimensional arrays, not structs per se.
i.e. void myfunc(thing* stuff) { return; }
int main() { thing stuff; myfunc(&stuff); }
I'm sure the problems I had could be solved by either a full re-design (not really an option), or accomplished by someone with more C experience.
(I am getting ready to write an essay titled "Confessions of a Shitty Programmer").
It was... terrifying.
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.
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.
Now, I wouldn't necessarily use PHP for this sort of work, but...
Those 100 line functions wouldn't make it through any half decent code review. Zero modularization, dal is inextricably linked to almost every piece of logic in the thing. Its an object called "Bitcoin" and I have a feeling it is 95% of mt gox' business logic if not all of it, it even writes raw xml to a temp pointer before dumping it into a cache and then making calls to header(). Separation of concerns? What are concerns?
Sure its tabbed neatly, and its got camelCasing, its using some form of orm/query thingy going on in there, but its still one hell of an unmaintainable, untestable mess.
I'd rather a thousand lines of spaghetti than ever having to work on something like that.
That and "this looks kind of structured from the top but the more I look at it, the less structured it becomes."
Bad, evil, horrible code written by misguided children makes the world go around.
True but I have worked on worse. The codebase we inherited from SQL-Ledger is quite a bit worse and was even more poorly commented when we forked (the only comments, aside from two lines describing the module, and copyright notices, were magic comments which if you delete things, stuff breaks).
And some of the modules were 4-5k lines with 1000-line functions. In a codebase of over 100k lines :-P. As we continue to pull out this logic, our codebase increases in functionality and decreases rather significantly in size.
Oh, and it was Perl which relied on sloppy global scoping and so you couldn't test it.
But hey, we are replacing the code at a pretty good clip.
What is really frustrating with the SQL-Ledger codebase (at least as of 2.6 and 2.8, I haven't looked at 3.0) though and is probably the case in the code you are linking to is that the developer had over 10 years of progress in this and still never seemed to manage to improve:
IS->post_invoice(\%myconfig, \%$form);
It's one thing to write crappy software. It's quite another to write it for over a decade and never improve.
- 2 decades in development
- just under 3k "scripts", mixture of php html "fusion", php classes, and last decade or so templates have been added
- last wc -l check, was well into 1m lines in house code
- database (we have a few), >300 tables, it used to be around 4 but we culled some tables / systems
This is our oldest system, still in use, still extremely business critical, we're doing a similar thing to you moving things out, cleaning house so to speak. But its going to be ongoing for a long time to come thats for sure.
Some of the people in this thread should get together and start a new dailywtf clone. Pretty sure we could preload a years worth of content with nothing but grep and git-log.
Unfortunately the fact is once you get to a certain point you pretty much have to accept that you are going to have some inconsistency and rewriting is going to happen gradually. With the LedgerSMB codebase, we have a mixture of code before the fork, which is a mixture of Perl spitting out HTML as strings in pieces and Perl assembling db queries in little pieces, so your comment made me somewhat uncomfortable because it reminded me of what I am going through in the rewrite process.
> - last wc -l check, was well into 1m lines in house code
wc -l was in my case closer to 200k, but once you exclude blanks readmes, documentation and comments we added, it got down to about 100-130k. Not really sure.
However, the code was messed up in ways that are only possible by taking powerful features of a language and systematically abusing them. In the db, needless polymorphic associations which served no purpose.
Almost every module had a name of exactly 2 letters, and the scope of some of the modules was just breathtaking. PE.pm for example handled logical groupings of parts for point of sale, customer discount groups, and project accounting.
Now if there were modules that did too much, there were also modules which were divided for no reason at all. You had, for example, ar/ap workflow and user interface split between aa.pl, arap.pl, and arapprn.pl (the latter being printing support functions).
This is code that every time I work with it, I find unpleasant surprises lurking beneath the surface. It is code that when we forked failed basic tests for things like rounding numbers (financial app). We fixed that right away.
If we are lucky we will be done with the rewrite in another five years.
> Some of the people in this thread should get together and start a new dailywtf clone. Pretty sure we could preload a years worth of content with nothing but grep and git-log.
Definitely. I am up for it. Should I start a blog and post the url here? I would be happy to add you.
... Or may be I think like that only because I can see myself almost in every single line author posted :)
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 :)
Unfortunately, I repeated the same year of experience in the middle a few times...
Nowadays, I am getting better. If I don't understand a bit of code I wrote a few months back, then I use it as an opportunity to look at it freshly. Why is this code crap? Why is it making what I want to do difficult? How could it be better? That's a good place to start refactoring from.
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.
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 ;-)
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.
sitting down and learning a bunch of patterns and then using them without a deep understanding of why they are useful is misguided, and you'll end up with dogmatic code. not that it won't help, it's just not the most important step. the most important step is to write at least medium sized code bases without putting your ego into them so that you can be savvy to your mistakes.
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.
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.
--
"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 )
I'm sure there are exceptions to this, but they are hard to find and universities aren't entirely to blame for it. Some parts of software engineering move fast and there is a justified fear to teach students things that will be useless by the time they graduate. So the focus is more on laying a solid ground-work.
http://webcache.googleusercontent.com/search?q=cache%3Awww.m...
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.
"File under ego"
10 PRINT "COCKS"
20 GOTO 10