Slashdot Mirror
Taking Your Programming Skills to the Next Level?
An anonymous reader asks: "About 6 years ago I graduated with a degree in Computer Science. Since that time I've been working on and off as a programmer, however I feel that my programming skills haven't really progressed to the next level as I had hoped. I guess part of the problem is that my work environment hasn't been especially technical or challenging, so I really need to try and improve my skills independently. What strategies did Slashdot readers use to improve their programming skills Which books are useful in this area?"
If your current job isn't challenging you, then get out of it now. Do not delay.
All you are doing is painting yourself into a corner skills-wise that is going to get harder and harder to get out of later. The longer you're doing this basic stuff, the rustier and rustier all the real actual knowledge you got out of your degree is becoming.
Employers don't want rusty people, they want people with skills already.
Get out now.
NZ Electronics Enthusiasts: Check out my Trade Me Listings
To me, it sounds like you are not really that interested.
I have a feeling that I'm going to be modded troll, but if you know how to program properly you can teach yourself any language without much difficulty and therefore tackle any challenge you place before yourself. Give yourself and insanely unrealistic task and then force yourself to follow through on it. If you can mentally build a road-map to making it happen, you're ok, if not, you may wish to try a new career or remedial programming courses.
I may be wrong, but the submitter doesn't seem like the type who's going to pick up another language or solve some useless problem "just for fun." That's okay though, because I'm the same way. I hear about people who program shit in their spare time just to solve trivial problems, and I just cant get into that. However, I am a fairly good programmer. In my case, the reason I became good is because I went to several different jobs, and in each job there was some sort of major problem that the company or team had been dealing with for a while, that I decided I could solve. The difference between that and solving useless problems in my spare time is that a.) it makes my job easier, and b.) I'm getting paid for it.
I've made most of my money over the years (not that I'm a millionaire or anything but, hey, I'm still young) doing automation work. I see a manual process being used, decide it can be automated, and I automate it. That's the sort of programming that really gets me going: programming that makes life easier.
So, I guess my advice for those unmotivated to do things on their own time would be this: Find a problem at work that can be solved through some sort of program. Solve it. This could be automation of a monotonous task, or it could be writing an application to replace some boneheaded spreadsheet that everyone has been using for years to track inventory.
The upshot of all of this I guess is that I agree with you that practice makes you a better programmer. However, I would encourage people to look for problems in their work lives that can be solved through programming if they are too unmotivated or otherwise occupied to program in their spare time.
but have you considered helping on a open source project? Depending on the project (and yourself) you could learn a lot. It being a real project with a real team, etc, should sufficiently motivate you.
As for books, pick up K&R & read it, work the execrises, repeat.
Best of luck.
What was your minor in college? Sounds like someone needs a change of scenery.
-- I prefer the term "karma escort."
I recommend you the following essay (or any by Paul Graham for that matter):
http://www.paulgraham.com/avg.html
If you have a boring programming job such as coding Java web apps (as I do) it is particularly important you turn away your attention from the mainstream (e.g. the framework of the week) or else you too may become yet another boring corporate drone.
It is also very important to avoid fads (such as PHP) as well as stuff that gets a lot of attention but only because of the huge publicity behind it and the swarm of clueless people who fall for it (.NET, Windows whatever)
Finally, it is essential that what you work on is interesting in itself (to you, of course), otherwise no matter how effective a way you find to make it, it will fail to inspire you and without inspiration your mind will deteriorate.
There are many many sub-disciplines of computer science out there, and the "next level" you're looking for probably involves some degree of specialization. Data mining? 3D in gaming, or photorealism? UI concepts? P2P? I think you're looking for a focus.
I don't think improving your programming skills is really a worthy
goal in itself.
You can be the most skilled programmer in the world, but if you
just spend your time working on private projects or Top Coder or
whatever then you are no use to anyone.
To many people programming is an overly academic exercise in
self-improvement or entertainment, but really what is it is a valuable
engineering skill that can be applied to make a positive difference in
the world.
If you work on projects you are passionate about the rest will come.
To have enough spare time to do all the stuff people suggest here. Being married with a family, between commuting, working, doing chores, keeping wife happy, bring up children etc. I get maybe 30mins to an hour a week to myself and then I spend that working on website I sort of inherited after the previous editor bowed out. My commute could be used I guess to do a bit but that's the only time I get to listen to the news etc. on podcasts.
I can't even imagine having time to learn a language or play with programming for the sake of it.
To all those who have the time for this, enjoy it while you can and appreciate it.
I want a list of atrocities done in your name - Recoil
``Funny. That sounds an awful lot like a CompSci degree.''
I _wish_ CS degrees actually taught people different programming languages these days. And I don't mean mentioning them in passing and showing a few snippets of code, but _actually_ making people use the concepts of these languages and recognizing the value of these concepts.
Please correct me if I got my facts wrong.
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
- So far, every time I have changed jobs, I've had to work hard to adapt to the new environment. New environments will keep you on your toes on different technologies, introducing you to new concepts which probably apply to various platforms. Once you've seen Oracle, MySQL, PostgreSQL and SQLServer, you'll likely know how to handle databases. Once you've seen PHP, JSP, ASP and CGI Perl scripts, you'll probably be familiar with the underlying concepts of server-side web programming. See a few flavors of everything and you'll readily adapt to new environments.
- It's not just about learning new programming languages and platforms. Perhaps to you "The next level" means fewer bugs. Do you already consistently write unit tests? Document requirements? Perform regression testing? Have your code tested by collegue programmers? What about code reviews/code reading? Is your code maintainable? Readable? User-friendly? Well-documented? Bug free? How can you (automatically) prevent these bugs next time? How familiar are you with the infrastructure of your programming environment (version control, build servers, network, etc?)
- Get familiar with 'new stuff'. I first heard about "Correctness by construction" here on Slashdot. Follow the white rabbit and find out what Spark Ada has to do with this.
- Learn to do things by yourself, even just as hobby project. Although nowadays it is relatively useless to write your own file compressor/database engine/scripting language/GUI framework/chat program/network protocol/file system/operating system, doing so will give you massive insight in how these work in general.
- Find someone with whom you can discuss better ways to do things. You will pull each other up. Show your code to each other and discuss improvements. Keep in mind that other programmers sometimes have an opposing view from yours. This doesn't mean that one is right and the other is wrong. (Example: What is better, a micro-kernel or a monolithic kernel? Answer: The truth is probably somewhere between those extremes.) The importance is in understanding the shades of gray between the black and white.
- If you want to learn, first you must get rid of the strong ego that most programmers build up over the years. Most programmers with a strong ego don't deserve their arrogance anyway.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
Someone calling 'Java Web Programming' boring and PHP a fad. [sarcasm]Gee wizz, what kind of person could that be?[/sarcasm]
1) Neither Java or Webprogramming or both together are boring. It's jobs and projects that can be boring. If it isn't your thing, don't do it. And if the webstuff your doing in Java actually *is* boring, you might want to consider switching your framework? The current, somewhat justified hype is Rails but I'd actually suggest Symfony. Which, in second instance. is a PHP framework.
2) Sorry to be raining on your parade, but you're talking out of your ass. PHP isn't a fad. It was an Open Source SSI template solution that scratched an itch ten years back that could be solved satisfactory with Perl alone. Now it has grown to number two in the server side game, moping the floor with Cold Fusion, ASP and a few failed, sad and sorry attempts at consistent Java webframe projects. It's easy to learn, has by far the largest amount of very mature and successfull OSS webprojects and scares the living piss out of BEA, Intersystems and the occasional MS web plattform division.
PHP is a descendant of Perl and thus simularly crazy, no doubt - but calling it a fad puts you in the classic position of an anti-social, they're-all-holding-me-back Lisp/Ocaml/Eifel/[fill in rare academic PL here] crack that's actually best off *not* doing any stuff that requires frequent team interaction, such as - believe it or not - web projects. Ever considered doing exotic science stuff on large supercomputers or bio-IT or so? Chances are you'll feel like a bug in a rug in those fields.
Real world programming is about learning to cope with the restrictions of the real world, called load distribution, wacky and stone-age database concepts (you call PHP a fad but don't lose a word on SQL - how am I supposed to take your opinion for granted?), inconsistent and/or non-existing developement pipelines in dire need of updating, shoestring budgets and the occasional boss/client poping in and overthrowing everything. Programming and IT is about helping the people along, raising your boss/client to be aware of the needs of solid IT and it's resulting advantages and, in the end - believe it or not - acually delivering marketable results. All together makes up the skill of a good programmer. Pick your technology - whatever it may be it doesn't matter, only OSS may be a prerequisite - and get on with becoming one.
That's 2 cents from a client- and server-side web developer.
We suffer more in our imagination than in reality. - Seneca
The parent post is alreday +5 Insightful, but I'd like to add that another way to get better at programming is to find a mentor.....a good mentor. I made the biggest leap in my ability during my first job (which was rather fortunate). I was on a team of young guys, but we were all sharp. Where one of us lacked, the other was strong. After 5 years, I was a very well rounded programmer. I try to continue that by always having someone that I've taken under my wing to mentor as well. So, if you're in Austin and want a top notch database programmer (not a DBA) to be your mentor, look me up.
Another area that will help you is breadth of knowledge. You don't have to be an expert in everything, but be aware of many fields (different tiers, different languages, different layers of the network model, what have you). This helps because you will quit fighting to put part of a solution in the wrong layer. If you can push it to the right layer, your solution will turn out better (easier to write, easier to maintain, more robust code, better overall design).
Layne
Rather than typing two pages of code, it's only half a page(big deal).
Umm... elegance is not measured by terseness. It's measured primarily by clarity, ease of maintenance, ease of extension, ease of code reuse, and probably many other factors. What you describe is "clever" code, but it's not necessarily elegant.
BTW, as an aside, writing clean, elegant code rarely pays off in the short term. However, 6 months or a year down the line (or, better yet 10 years), well written, elegant code will almost always pay off in spades.
Learning assembly language is similar to learning Latin.
You'll learn French, Spanish, Portugese and Italian much much faster if you know Latin.
http://blog.grcm.net/
Heck, 3 months down the line in my experience. And it always pays off. Even the first time. Try going back over your last project to fix those bugs. Yep - much easier usually with "elegant" code.
The cesspool just got a check and balance.
Not having had the advantage of a formal education (I have a GED and otherwise I am self taught) I've had to resort to, in some cases, drastic means of career as well as technical information acquisition. I have found the following to be consistently true.
1. You are rarely given additional responsibility (i.e. new projects, new technologies, "hard" stuff) at a job without first proving that you can do it. This usually involves doing things that "aren't my job" without getting paid for it for a certain amount of time and then being your own advocate after the fact. No one deserves anything on their own word. Find new things going on at work and put yourself square in the middle of it. Nothing interesting going on? Start analyzing the development process and environment and propose ways of making it better (and ofter to execute said plan).
2. Read. A lot. I highly recommend O'Reilly's Safari Bookshelf thingie. Some people don't like to read on line and prefer "real" books. I think that's cool, but you can't let that be a reason why you don't read. If you can't afford to buy all the new tech books you want to read, get a library card. Live in some strange place with no libraries? Find a way. You will if you want it.
3. Read non-technical articles and resources about the development process, software design and architecture, intergration methods. You know, "sciencey" type stuff. I find that I like certain authors more than others. For instance, Martin Fowler (http://www.martinfowler.com/) is the author of many excellent books and is known for his work in design patterns and architecture. If you read nothing else, read his work. Remember there's a much bigger world than writing guest book "scripts" 10,000 times (and thank insert-deity-here that's true).
4. Talk to other people. Anyone. Everyone. Project managers, developers, system administrators, architects, analysts, QA folk, telco employees, and anyone else that will give you the time of day. Learn what they do, how they do it, why they do it that way, and how it effects what you do and why. You'll have a much better understanding of distributed computing if you understand network and security principals and how they apply (and you might just not open up yet another SQL inject bug because of it).
5. Commit yourself to improving your craft by practicing it. Constantly. I find that being involved in open source development is 100% free peer reviewed experiance. Additionally, the open source work I've done in the past has won me a job or two. You never know when you might meet someone important to advancing your life.
6. Consider everyone you meet a student who may benefit from you, but more importantly, a teacher no matter how much smarter you think you are. Discuss, debate, learn, integrate new knowledge, repeat.
7. Find a mentor. Someone willing to take you under their wing (whether they know it or not) and soak information from them like a sponge. Don't know one? That's why I said *find* one. Very few people learn things themselves. Most people are taught by others, if by written or spoken word, code, IRC, or otherwise. I can't stress the mentor thing enough. Find two. Three is better. Find mentors that don't agree with one another and compare ideas. Learn from everyone.
This is what has worked for me. I dropped out of high school, got a GED ("good enough diploma"), and got really lucky in meeting the people I did. I do software architecture and design for a living in addition to mentoring and "grooming" developers. I learn more from them in a single day than I learned from any book (give or take).
Good luck. If you're trying to figure out why you aren't where you want to be or why you haven't attained what you want, you're already a step ahead of everyone else. You'll be fine.
By understanding how the compiler converts the code, you can optimize your code to allow compilers to work more efficiently -- ie. i=2; if (x) i=5;
Understanding how a compiler optimizers code is a very different thing than just understanding assembly language.
In some sense, you need some level of assembly language to compare the efficiency of the code generated; but it's still a non-trivial task to read the source code of a compiler, and determine, for a given set of generated code, which will perform the most efficiently in the long run.
It depends on the compiler, *and* on the architecture. If assignment (writes) are more expensive than comparison (reads)(say, on a device that uses flash RAM ), you've just prematurely optimized for the wrong thing. What's more, if it's obvious to you how to arrange the code, it probably was obvious to the compiler writer, too. He has, (at least hopefully), spent more time considering the problem of how to optimize the output of his compiler than you have.
In other words, if it's always obviously faster better to write: "i=2; if (x) { i = 5 };" than "if (x) { i=2; } else { i=5 }", a good optimizing compiler will convert expression 2 into expression 1 before compiling, anyway.
And if you have enough free time to read, understand, and re-write the assembly language generated by your optomizing compiler to fix the compiler bugs, you've probably enough time to re-write your high-level program to avoid the bug. Developing bug-free compilers, especially bug-free optimizing compilers, is hard, slow, painstaking work.
In short, learn a bit of assembly, if you want. But don't overestimate the good it will do. Unless you're working specifically in embedded systems or compiler development, it's all just academic, anyway. You'll never have time to use it under high level language development timelines.