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?"
Practice. Learn a new language, just for fun. To do so, program a new application to do something useless that has been nagging you for months.
Yeah cuz programmers definitely need more hitpoints.
A Good Troll is better than a Bad Human.
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
Typically, you have to rescue a kings daughter or defeat a marauding ogre that has been terrorizing the townsfolk. That's how I got to be a level 9 Programmer, although the +2 keyboard, +3 against fire elementals, does help. If I take it to the next level, I get an enchanted chair.
there is no need to sign your posts. this isn't usenet. your username is right there above your post. stop it.
To me, it sounds like you are not really that interested.
Learn assembly language and write a simple app like rudimentary text editor or line-art drawing tool, something that requires most of the basic IO functions. (Then try an application launching menu - yay memory management! :)
This will give you a foundation that will apply to every other language in the world and damn-fine debugging skills as well.
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.
Did you ever notice that *nix doesn't even cover Linux?
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.
Find a project you're interested in, see what needs doing and get involved. Contribute patches, propose ideas, ask for feedback from more experienced people. You can practice a number of important skills this way both technical and social. A big part of working with others is that you get to start understanding how other people think--that will both grow your understand and help you understand where your natural boundaries are. You need both those things to grow.
Cheesy, but true. Nobody is going to just push you into a position where you have to stretch yourself, unless you are very lucky (and so far, apparently, you haven't been).
... limit yourself, and learn to grow around limits.
Choose a project. Maybe only for you; maybe it only makes sense to you.
Evaluate different non-mainstream languages for the project. (Good places to start, IMHO: assembler, erlang and FORTH).
Decide on programming standards. Give yourself reasons for them! Good reasons include maintainability, expandability, explicability.
Execute.
Debug!
Now choose another challenge, do the same thing, but choose one on the brink of feasibility. Make it feasible, using knowledge of mathematics, computer science and so on.
Do it on old, slow, busy hardware. Make it pleasantly fast to work with. Make it not require much (anything!) from the environment. And so on
I would recommend volunteering for a GPLed project in a domain that you want to improve your skills in. The real-world issues you'll face will surely improve your skills in domains thet you are interested in. The books/material you would have to read will get driven by this project's needs.
This is not my sig.
Write a driver for Linux - preferably a useful driver that 14-17 year old demographic (Which pretty much covers every Linux user) will want to use. With every point kernel release, you'll be forced to update your driver, sometimes having to completely rewrite it to keep up with trivial (and seemingly useless) binary kernel interface changes, and at all times wondering if there even is a binary kernel interface.
Motivation to update your driver won't be a problem because every time a new kernel is released and your driver breaks, you'll get hundreds of reminders (death threats) from Gentoo users who just ran emerge '--universe -09* --funroll-loops' on their Mom's old E-Machines box, that you need to fix your driver.
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
I had a job at a large corporation...not too much programming, but (eventually) lots of networking, support etc..
I streached my wings and found places where I could do some programming to expand our capabilities, still within my job function.
Eventually (after about 7.5 years at that company, which I started at straight out of college), I quit (lots of other reasons, but I was also just burned-out and not challenged enough). I took about 8 months off, learned C (only got Pascal and a smattering of other languages in college), and developed a variety of windows based utilities etc.. Not so much to sell, but as a learning experience. After that break, I slowly started back into the regular work-force, but aimed myself at a programming job (but now had lots of other experience behind me).
Now I have a great programming job, working on a variety of projects, and lots of flexibility.
I never had aspirations to be a game developer, business oriented applications and services are more my speed. Try to decide what area you want to develop in, then aim yourself via classes, books, etc. towards that goal.
Give a hand, not a hand-out.
Six years out of school and "programming on and off" seems strange. What kind of programming do you want to do? GUI stuff? Graphics? Games? Algorithms? Databases? Real-time?
One way to get better as a programmer is to do maintenance programming on code written by someone better than you. Learning to understand someone's thinking by reading their code can be a worthwhile exercise. It's also useful to be able to write in someone else's style.
Right now, something worth getting good at is understanding how to write highly parallel programs that are reliable. Write something that has lots of intercommunicating threads and be confident the locking is correct. There aren't that many people who consistently get that right. You have a CS degree, so you have the theory for that. Put it into practice. The world is full of underutilized multiprocessors. Learning how to write safe concurrent code will definitely make you a better programmer. (It will also make you realize how bad most mainstream programming languages are for this.)
On the language front, today I'd say that you should be good at either Java or C++ (C# if you're in Microsoft land), and either Perl or Python (VB if you're in Microsoft land). One strongly typed language that goes fast, and one weakly typed interpreter. Basic familiarity with the HTML/PHP/Javascript world is useful, but don't spend all your time on the details of that - that's for low-level programmers with two years of experience. Also, learn how and when to use a relational database, at least at the MySQL call level.
Start doing some personal projects in a different language to the one you're exeperienced in.
If you use an object oriented language, then learn Smalltalk, you'll definitely learn some stuff that you'll be able to apply to your main language.
Advanced users are users too!
Commune with your inner Angband variant.
...No seriously. If you join an IT department where you're the "big fish in a small pond" people will start to notice, they'll give you the tough jobs (note: NOT read as "fun" or "challenging") and because the rest of the IT department is crap they'll pile it on and I mean it. If you find the right place (i.e. the worst place) they'll stack it up and then slam you for not getting it all done sooner.
Instead of sinking under all that work, it will become you're motivation to raise your game and plow on through. You'll find new techniques to get work done, you'll learn to identify the patterns that get work done in the department and you'll invent new processes out of those patterns. When you start to succeed, you'll master your job and maybe a programming language or two.
Then when you're feeling confident about your skills, QUIT that job and go join a firm with a good reputation, knowing full well you're ready to play with the big boys.
But seriously, don't go searching for a book or learning material. Search for MOTIVATION. It's through motivation that we test how much weight we can pull and it's motivation that will select the subjects that we want to study the most.
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)
Download the Microsoft XNA framework and build a game!
Being a programmer myself and looking for answers, finding most of them on my own and finding other on this thread :), i find some interesting observations.
To be a good programmer you need practice for sure, but you need stimulating challenges to work on.As in my case i found that to be the Linux kernel.I may not be the best of the kernel hackers but yes i have a passion for kernel.I work on an entirely different area at work, which is C++. But my inqusitiveness and quest to be a good software programmer has led me to realise one thing, you are on your own. Try to learn from your mistakes. More you make them, more you learn.And who knows down the line may be after a couple of years you can be a pretty good programmer.
Working for a GPLed project is a good idea but you need certain level of expertise for it. And effort you put into your passion for programming will get you to that expertise. Once it is achieved you can choose a GPLed project of your choice and certainly you ll hone your skills for sure. Good luck :)
-- "Genius is 1% inspiration and 99% perspiration" - TAE --
1) Try numerous languages (C++, java, php, python, PERL, lisp, scheme) -- you don't need to become proficient in all of them. Learn their mechanics, their strengths and weaknesses, what fields they're applicable for, etc (ie lisp and scheme are practically de facto AI languages; PERL treats a regular expression like it was a plus sign). The more languages you're familiar with, the more abstractly you can program.
/do/ need. If you build your knowledge around being able to program 3d engines, AND being able to do web development, AND being able to do xyz completely different CS field, you'll be good at none of those things.
2) Pick a language you're comfortable with. Learn every wonderful, disgusting detail of what you can do with it (our head programmer knows more about php than its developers do). Preferably, pick one that's managed for now (ie not C++ or C) so you spend more time programming and less time worrying about memory leaks. Yes, unmanaged code is faster, but you're learning about being a _better_ programmer, not writing an operating system.
3) Give yourself projects that you know are beyond your scope. Pick something you're interested enough in that you'll stick with it if it gets annoying. For example, I taught myself php and sql by writing a Character Manager for a roleplaying game. It's not pretty, it's not the most efficient it could be, but it served its purpose; I wrote it from scratch, and every time I learned something knew, I rewrote half of it. Certain languages (PERL, Scheme) you really have to give yourself a goal in order to stick with. You're never going to learn anything about programming if you're not working on something you care about. Stuck on how to do something? That's the point. Find out how. Look it up on google, or better yet, Google Code Search. Plaigarism schmaigarism. You're learning, and no one's going to use your stuff but you.
4) When you write a piece of code, think logically through how it works, how long it takes in best case, how long it takes in worst case, etc. If you have time, look into Time Complexity Theory, but in most situations you should be able to tell if it's a god awful way to do the job, even if you can't think of a better way at the moment. Make it as efficient as possible (or at least understand what _is_ the most efficient way, had you the time to implement it), and move on. My first CS teacher took points off because my algorythm iterated one more time than it needed to. That might sound silly, but when it's running 1000 times a second, it counts.
5) Do the pthread dance. Write a multithreaded program that does what it's supposed to do, every time.
6) Learn about security, buffer overflows, sql injection, etc. Hack your own software.
7) Books -- skim lots of them, read very few of them. All that reading books gets you is a lot of knowledge, but many times not a whole lot of application. Read the tips and tricks that stick out. O'Reilly books are great for that sort of thing. One of theirs you should definately skim very strongly is "Mastering Regular Expressions".
8) Don't be afraid to specialize. If you like web development, do it. If you like a specific language, use it. If you want to write simulators for gravitational wave theory (I have no idea, but it sounds obscure enough to me), go right ahead. Someone will need what you're putting out there, and if they don't, you're probably learning skills that apply just as well for what they
8) Don't burn out. If there's another problem you feel like working on more, stop whatever you're doing and work on that instead. Write stuff for Open-Source projects. Find bugs in open-source projects. Read open-source code and try to figure out just what in the hell it's doing. Think about how you could do it better.
You get the idea.
Challenge yourself with something difficult. I don't mean writing a new Compiler or RPG. Something you actually need or would like to have.
.NET C# then some of this doesn't apply. In general though, I'd say getting experience in working systems in a number of languages is very useful as it teaches you to design a program in general, rather than how to do something specific in a set language. Good programmers are good in any language.
Projects I worked on included writing
- a small RT OS for it to interface to my computer to perform maths routines faster, all programmed in assembler and later in C.
- a multiuser 3D based engine (including all the 3D rendering and lighting routines - this was in the early 90s) in C and assembler
- a python based server monitoring system with awk and perl agents
- a neural net based artificial life form in C++ (it didn't work but I learnt a lot!)
There were lots more but these took from a few months to a few years to complete. Each one required going off and researching algorithms and software design and languages. The actual experience gained was used in later jobs and I've used the above items in my resume and it has helped because some employers have seen those and realised that's just what they need (though they never advertised the fact).
Also, use other people's code as examples or starting points. I learnt a heck of a lot trolling through apache or freeciv or Small-C or so many other things just trying to find some code that did what I wanted or trying to mould a program to my own purposes.
It is critical to learn how to write well laid out and documented code too and how to craft a good Makefile.
Now if you're going to do SQL coding for a living or
Make sure the hobby projects are things you'll actually use yourself, so you will learn to maintain code and will get annoyed if it has bugs. Better still, make it something other people use too so they'll tell you about the aweful UI you design or the bugs you'd never find yourself.
pithy comment
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.
Here are 42 books that have helped me.
StoneCypher is Full of BS
I have to say, this sounds a lot like my current situation. I've been out of college working for a few years now, and I always imagined I'd get a job that was challenging and that the learning would never end. But after working in my current job for 2 years, I start to feel that I'm wasting time. I hear about all the neat things other people are doing, and start to feel impatient since I know I'm still in the same rut (simple web applications).
One thing that helps is finding ways to get into different technologies and different types of problems within your current job. That way you're exposed to more things and makes it a little easier when you start looking for a job.
The best way to learn for me is the same way I did it through high school and college; figure out how to do something that interests you personally and spend your free time on this. This method worked great during school since I had lots of spare time. Since I've started my "real" job, however, I don't spend any time on personal projects. The real kicker is that I realize that the projects I've been putting off for a year or two are the exact ones that would give me the skills I need for the jobs I want to get into now. As it is, I have the skills neccessary to do something like my current job, which isn't satisfactory.
I need to set aside a certain amount of time to working on my own projects, so that I don't stagnate in that area. But the only real solution is to switch jobs and find something that does challenge you. My current job could become a career, is very stable, and could be very profitable and secure. But the big drawback is that I know I wouldn't get to do the work I want to. So I'm leaving. What good is all the secure stuff if you don't enjoy it and it basically shackles you away from doing all those other fun things you want to get around to?
We'll see how this pans out in the next few months. I'm hoping to find a new job that where I can learn some cool new stuff as part of my job (instead of "in spite of my job") and take a little-to-no pay cut. If it works out, then some of the things I've wanted to learn on my own will happen naturally as part of my job, and at the end I'll have more diverse/mature skills and not feel like a horrible joe-vs-the-volcano cog in the machine. Blech.
Good luck.
I have to admit many times I'm the same way. I have trouble finishing personal programs. Probably only about 1/4th my hobby programs end up completed. But it's not as bad as it sounds. Many times I'll just solve the difficult parts of a program and that'll be good enough for me. So for example, for many people the next step is dealing directly with hardware. Get some simple hardware like RC motors and get them to do some simple things. Don't worry about a complex program, just solve the problems you currently can't mentally work out quickly. For learning purposes it's the next best thing to actually writing the program end to end. Espically if you have a hard time getting motivated for the boring parts.
If an officer ever threatens to taze you, say you have a pacemaker.
Even though I have 29+ years of programming, I have never worked for a company that had its stuff together as far as product development. They all were poorly conceived, constant moving targets dictated by the sale's department's conversation of the day.
As far as learning new languages go, that's fine - if you are not already there - I was at the point quite a long time ago where 'its just another language'.
I finally forced myself to do some small projects in text book perfect approach - requirements - use cases - UML models (and appropriate design (not refactor) patterns - Test driven development. The results were some incredible complex multi-threaded x25 to tcp bridge code that worked first time and was a pleasure to enhance. Never before had I experienced that, and never again since either.
Anyhow, that was a personal accomplishment / satisfaction. Now if I could only find a company that builds software this way.
slashdot troll = you make a compelling argument I do not like the implications of.
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 agree with earlier posts about finding a new job that is challenging. However, I think you need to ask yourself what skills you really want to improve. "Programming" is not really a skill in and of itself. Different jobs will challenge you in different ways, and depending on your personality and career goals (if you have any), you need a different challenge:
1. Analytical Thinking. All the comments about learning math, a dozen languages, etc. are all really focusing on the idea that programming is about applying computational theory to problems. Algorithms, complexity, correctness, etc.
2. "Applied" Philosophy of Language and Mind. Some will argue this isn't separable from the previous point, but an aspect of programming is the expression of complex analytical ideas in different forms. Beyond the mathematical equivalence, you learn that there are many other qualities to these expressions, making them more or less suitable for particular purposes. For example, expressing them for the benefit of a stupid compiler/execution system versus for the benefit of other human readers. You can learn a lot about computation by understanding the essence of "semantics-preserving transformation" of programs and phrases.
3. Software Engineering. An entirely different aspect to real-world programming is the methodology to identify problems, design solutions, implement designs, and validate solutions while managing risk and cost. The best way to learn in this area is by going to work in an established engineering organization. When it ceases to be challenging, be ready to move again.
4. Psychology and Rhetoric. Don't shoot me for lumping these together, but they are two important aspects of interacting with fellow humans in a productive way. You need to understand how/why people are reacting to conditions beyond your control, and you need to predict how they will react to actions you haven't taken yet. Rhetoric is the subset of this that focuses on speech/communication acts. This is fundamental to advancing in the software engineering space to become a leader or manager of teams.
5. Specific Languages or Systems. This is where the danger lies for a young programmer. You can quickly open doors with the right skill-set, but you can also quickly close them. There is danger in becoming a specialist in order to find jobs, as opposed to developing a range of specialties through work experience.
As someone 10 years out of college and who advanced from entry-level programmer analyst to senior architect, working in academia, startups, and interacting with some of the traditional big programming organizations, I think it is wise for young programmers to make sure they are prepared to go it alone. The days of job security in a programming position are fading fast. Get some entrepreneurial skills and consider a future where you might be an independent consultant or principle in your own company. However, take advantage of employment opportunities with established companies to use them as a training ground. Learn what they do. Integrate the parts you like, and think about the parts you don't like too. It may take years of experience, new jobs, and a different context before you appreciate the value of some methods you will witness when starting.
0) go back in the archives and find a contentious 'my favorite language is' debate
1) make a shortlist of n of the most passionately argued responses
2) go back in the archives and find a contentious 'this was my worst programming problem nightmare' debate
3) make a shortlist of m of the most passionately argued responses
4) create n x m language/problem set and program n solutions to your m problems
5) post your findings; adjust n, m to suit your available time accordingly but preferably expand them a bit; change "worst" and "nightmare" to "most interesting" and "challenge" depending on whether you're a pessimist or optimist
Get on TopCoder and try out their problem sets or participate in their contests. You'll soon find out how bad you are. :)
Best of luck!
I don't know about books per se, but these links help:0 Patterns/
P rogramming.html t icles.html
http://joel.reddit.com/
http://programming.reddit.com/
The design patterns book website with, as I understand it most if not all of the content for the book:
http://lci.cs.ubbcluj.ro/~raduking/Books/Design%2
The next three I keep the bookmarks to in a folder called "Practicing programming:
http://www.devblog3000.com/archives/2-Practicing-
http://butunclebob.com/
http://www.objectmentor.com/resources/publishedAr
Without knowing your exact skill level, it's difficult to give you advice. However, I can mention a number of things that I see a lot of coders doing wrong.
...
//log error message here //cleanup dynamically allocated memory and close files here before returning.
1. Not knowing when to use gotos in c:
Notice that I didn't say not to use gotos. Anyone who says that gotos are just "bad" hasn't programmed in c enough.
Strictly speaking gotos should be used, and *only* should be used in exactly two classes of programming problems.
1.1. Deeply nested loops that must be broken out of entirely on some condition of the inner most loop.
1.2. Error handling. In languages that support exceptions, they can and should be used, but in c gotos should be used in this way:
result = function1();
if (result == ERROR) goto error;
result = function2();
if (result == ERROR) goto error;
goto cleanup:
error:
cleanup:
As you can see the error section of code is equivalent to a catch block and the cleanup section of code is equivalent to a finally block. There really is no better way to do this in c (without macros wrapping longjmp like objective c does). Be sure not to get too fancy with your gotos here.
2. Learn object oriented programming techniques. A lot of people learn the very basics in school, and don't go much further. I'll list some areas to look into.
2.1. If you haven't already, implement some of the basic ADT's (most people did this in school).
2.2. Learn the special object oriented semantics of your language of choice. Every language has it's own funky way of being object oriented, and you need to know all the gotchas and the best workarounds.
2.3. Learn about various design patterns. Skim through the Design Patterns book, and try applying various patterns that catch your eye. The important thing that design patterns should teach you is how to write your code as a bunch of loosely coupled components.
3. Learn about functional langauges and generics. Both functional and generic programming revolve around a set of techniques and programming constructs that are increasingly supported in mainstream c based languages like c++, c#, and java.
Probably the best way to do this is to learn SML, or ocaml, as these languages are both functional and generic. Many people will recommend learning scheme or LISP, which is a language that is functional, but not generic. Personally, I think that scheme is a poor language, but it has a few interesting features like continuations that are worth learning about.
All these languages are academic languages not really suitable for real world projects (with the exception of maybe ocaml). The point of learning them is that they do a good job of introducing concepts that are becoming increasingly important in programming.
Aside from specific skills to learn, the most important thing that you do when you write code is to think about all the different possible ways it could be written, and choose the best one. Also, pay attention to the overall structure of your program. The best kind of program to have is made up of a bunch of components that individually perform very simple and well defined tasks. As a rule it's better to have lots of small classes than a very few big ones.
There's a lot more that can be said... but I think that should get you started.
try doing the "hello world" programming challenge. If you find it too difficult there are tons of websites that will help you along with this in any language you choose.
As someone still in college(last year) I am kind of trying to achieve the same thing 'taking my skills to next level'. This discussion has been of tremendous help(thanks /.). Ive learned a few varied languages and I am able to 'solve' most problems but I don't write 'good code'. I mean I do get the job done but its rather ugly. I do not see myself helping with GPLed works because I simply do not have that level of expertise but as a lot of comments suggested maybe studying the code will help me a lot.
I've been programming since I was 8 years old and making small games is what kept me improving myself. Even a small game can be quite a challenge. Another big thing is emulation (which is the one I'm into right now), because it gives you a very good understanding how computers really work. I prefer technical documentation on languages or APIs than books, I like to go straight to the point and then do some experiments. So, I'd start a little game and then I'll continue improving it with some graphics and/or sound, just to get the taste of different things.
I would say the thing that served me best in enhancing my programming skills was the insane variety of different programming assignments I had through the years. I started on a satellite positioning and monitoring system in VAX Fortran, then immediately became a Smalltalk programmer coding an expert system for computer maintenance, then jumped into network monitoring using Unix, X Window and C, then went to another company where I did Bayesian analysis of text messages in C on Mac OS, then document scanning and management workflow systems, then... well, let's just say I have no domain-specific skills, the only domain I have is pure software development. By working on so many wildly varying systems, I was able to learn the common attributes of good and bad software, how to quickly analyze software for problems and how to develop software more efficiently and correctly.
If you can't get a variety of different assignments where you are, change companies. If you work for a large defense company, the odds are good that there are many radically different types of software development going on, from business systems, to logistics, to embedded real-time systems. If you want to learn discipline, start at defense contractors. Business systems are far too loose and "get it out the door" to learn good software development discipline and skills. From what I've seen and worked with, I almost want to take all my money out of banks and brokerages and stuff it under my mattress!
Oh, and as far as learning from books, it just never worked for me. I always learned best from other people, and from existing code. Books are for reference, to look up details about languages, libraries, operating systems, and other tools.
By the taping of my glasses, something geeky this way passes
I'm 25, live in the UK, and have been a web programmer for 8 years, with no college tuition. I've just secured my first project management position, with a very decent payrise. I know I'm not the best programmer in the world, and understand that I have a *lot* to learn, but I know I'm good with the tech I use and project planning, and that's helped me secure the next step on my career path long before my other programming friends. Here's why: I like to refactor, and I like to plan. I've spent many evenings studying what languages I do know (PHP, SQL, JavaScript, XPath, XQuery, XSL) and the systems I use (Linux, Apache, Lighttpd, MySQL, SQLite, XMLDBs). I know their little issues, their niggles, what they're most efficient at, when to use them and why, when to use something else... and I've always enjoyed refactoring my code to as concise a statement as possible. Most people will be screaming "premature refactoring doesn't work!!!" while reading this, but it works for me. I think this is mainly because I don't spend days and days getting 1 script to work at peak efficiency, but every new script I do I apply what I learnt from the last one, and refactor in my head as I code, and I think that helps immensly when you're trying to learn new things. For the past 6 years I've worked in jobs where I was the main programmer in a small team, and its been on my shoulders to plan projects from database to design. If you really want to get ahead fast, get into a small team. Also, try some functional programming. XSL/XQuery is good, Erlang (i've heard) is fun, or some of the others previously mentioned in this thread. If you know OOP, FP will really stretch your braincells! Look at AOP also - JavaScript can be lots of fun when you throw in aspects!
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.
Learn Ada. You'll be amazed.
If reading books and self teaching arnt your thing, helping out a complicated open source project is a great way to learn more and help a good cause
- Code bashers - these are people who bash out endless lines of cobol (probaly VB nowadays) with no real feel for the craft
- Hippies - Hippies write good code badly. Once the problem of how to code this task is resolved they lose interest so the actual transformation of the concept to the written code is poorly executed
- Nerds - Nerds write bad code very well. Nerds become obsessed with particular techniques and will use that techniqu whether it is relevant or not. However their attention to detail means that the code is well executed
Looks like you, like me, are a hippie under these definitions.init 11 - for when you need that edge.
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
Look at source code from the masters of programing such as ACE, TAO, and BOOST. Look at "Design Patterns" and learn to recognize where and how each would be applied. Design your own patterns that could have been used for past projects, and "design" new patterns for new projects. Get your hands dirty in learning several programming languages and learn their strengths and weaknesses and be able to choose which is best for any given project, and be able to defend that position (you may have to). Learn how to program "secure code". (Its not as easy as you might think.) Learn reverse engineering, debugging skills, and know your operating system internals.
> Looks like you, like me, are a hippie under these definitions.
Looks to me like you wasted good money reading a piece of shit book written by an idiot. Perhaps he writes non-technical articles for idiots and has therefore decided not to do any research?
What strategies did Slashdot readers use to improve their programming skills
Try to think of some project you'd really want to do on your own, make sure it's challenging enough, and then use the ressources you need to succeed.
That's how I went from just knowing some Pascal from college to learning C and DSP (Digital Signal Processing) on my own. I had a precise idea of the project I wanted to do, even tho I had no idea what it would really take to succeed, but with the help of comp.lang.c, comp.dsp and the documentation they all advised me to provide myself, I literally took my programming skills and mathematical skills to the next level.
You just got troll'd!
If you want to get better at writing correct code quickly, I recommend TopCoder. I spent enough years doing ACM and TopCoder competitions that a lot of techniques have become mechanical, and I no longer have to think hard about them to get the details right. (Perhaps I could have achieved the same effect more easily if I used higher-level languages, but I like to work on performance-sensitive problems which require mutable memory and lots of system calls.)
If you want to design large software systems or create interfaces meant for use by other programmers, I'm less sure what advice to give. Try to get some exposure to different languages or library interfaces and figure out why programmers might like or dislike them, what might be error-prone about them, what affects ease of extension, how to hide unimportant details and allow a diversity of implementations, etc. Look at some time-tested interfaces, eg unix files or windows message queues. Try to understand what problems they solve, how they could be improved, and some of the trade-offs the designer might have considered.
Java: the COBOL of the new millenium.
I almost forgot - practice makes perfect, so try the Code Kata.
but can it really work ? even assuming perfect voice recognition and perfect translation abilities (which we don't have), Human interpreters often have to wait till the end of a sentence to be able to translate a word, and real-time word-for-word is totally meaningless, if not impossible.
As an example, consider german, which can put verbs very very far at the end of a sentence in a stack-like manner (a bit like postfixed LISP).
To put it mildly this is a very challenging project.
- 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
At the age of 14, Nadia Comaneci was the first gymnast ever to receive a perfect 10.0 score for a routine at the Olympics. A few years ago I heard a sports writer put a typical musty sportswriter question to her: How do you get a perfect 10.0 score? Comaneci's answer was anything but cliche: If you want to get a perfect score you have to try something difficult. While it seems like sticking with easy stuff is a good way avoid mistakes, it actually leads to more errors, because you aren't forced to achieve the level of concentration you need to do the easy things perfectly.
Marcus Aurelius said that we should strive for perfection in the smallest of things. There is no doubt that excellence requires this, but it is also not humanly possible to do if all you ever deal with are trivialities. I've done some sports coaching, and one thing I've learned from that is progress is always found at the boundaries of what is possible for a person and what is impossible for the athlete. Trying for what is impossible today is a recipe for failure and demoralization. What is often underappreciated is the degree to which staying with what is too easy is also a recipe for failure. Mastering every sport requires repetive effort in perfecting the basics; however without the stimulation of a challenge, the quality of that effort is severely undermined.
The answer for a programmer is that you have to find an element that challenges your skills in even the most routine of projects. It does not do to be too risk averse. Many projects lose focus because programmers spend too much of their time in blind alleys searching for a bit of intellectual stimulation. I'm consulting these days, but back when I ran a stable of programmers, I always emphasized that my guys find "take-aways" on every single project. A "take-away" is something you have at the end of the project that enhances your ability to do future projects. Sometimes this is a library or a framework, but I think the desire to create "intellectual property" sometimes creates premature attempts at framework creation. The basic content of a take-away is know how; once the know how is there it can be productized, not before.
No matter how trivial or routine the project, you must strive to find a take-away, otherwise your ambition dies and your skill stagnates.
Most people become programmers because they had a few moments of intellectual stimulation -- fun -- in learning how software works. If that's what motivates somebody to become a programmer, that's what will motivate him to become a better programmer, and to achieve his best. Put something fun into the requirements of every project -- whether it is a contracted deliverable or not.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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
C++ Programming Style by T. Cargill
Quite an old book, but it is great for learning how to identify dubiously structured code and then improve it.
Advanced C++ Programming Styles and Idioms J. Coplien
Again, quite an old book, but it covers "programming in the large" rather than than the nuts and bolts that many books describe.
Design Patterns G. Booch, et al
I was initially underwhelmed by this book, partly because the hype surrounding it was so great, and because I had already been using a number of the patterns without knowing it thanks to Java. However, the really useful patterns are nicely presented.
Apart from books, I learned a lot from picking over things like Glib, the utility library that underpins GTK+. The code is of a very high quality and includes a number of interesting ideas.
As well as programming languages themselves, it's worthwhile looking at things like unit testing and design aids such as UML. The Java web development gurus have focused a lot of peoples attention on the benefits of truly modular code, dependency injection, testing and so forth. This largely stems from the pain of early Java web development and a general dissatisfaction with EJB. I certainly feel I'm a much better C and C++ programmer as a result of doing a lot of Java work in recent years.
If you use that phrase in a sentence talking about anything other than video games, it's time to move from CS to an MBA.
After I learned and was first using C, over a decade ago, I realized that I was only using a subset of its power. This was solved by C Puzzle Book by Alan Feuer. This book breaks down the C language into small component parts and alternately teaches you and drills you on all the features and how to use them in small, incremental steps of increasing complexity. It is required reading for programmers using C, once they've learned the basics.
After you've learned the language in absolutely all its features, read and study Programming Pearls by Jon Bentley.
By the way, the great computer scientists and super coders are by and large not wealthy. If you want to get rich, get an MBA and then get very lucky. Being a super techie will mostly make your employers richer.
Anyone ever notice you never see a West Indian goth?
Oh God!!!! That's ME!!!!! Why didn't anybody tell me this SOONER!!!! I feel so ASHAMED!!!! I need to re-program my Segway to lead me off of the edge of a bridge. I think I'll use a variant of the Medial Axis Transform of the city model to determine best path.
There are also artists, who try to solve the problem efficiently and in an elegant way. My goal is to reach that state.
My website
Find some really good people and work with them and learn from them. That means, start interviewing for other jobs and use the interview to see if the new place has people you can (and want to) learn from.
Also look around at everything else in the IT sphere and try to learn from it. Most of the big things out there have some good points and some bad points. While it is easy (and popular in this particular corner of the web) to point out the bad points in chunks of technology, it is much more instructive to look for the good points and try to see how you can incorporate them in to your own designs.
My own coding took off to much higher levels when I started caring about the quality of my code (as I transitioned from computer games to network infrastructure). I.e. not - "how clever and fast can I make this?" but "how robust, easily maintainable, secure, standardised, etc. can I make this?". In making this change I realised that the two are not incompattible and my coding abilities increased loads.
Finally my own words of wisdom - programming consists of two parts - computer science and software engineering. Computer science is (more or less) the art of taking logical problems and redifining them in a special mathematical notation so that they can be understood by a computer, software engineering is (roughly) the art of taking everyday problems and redifining them as logical problems (plus caring about quality etc.). Chances are you are good at one of these and not the other, so turn around,face in the appropriate direction and start learning.
Not sure if your curriculum covered Design Patterns or not, but if you were well versed in them, I doubt you'd be feeling like you weren't reaching the "Next Level." Head First Design Patterns is a great book IMO. Also, go looking for stuff you don't already know. Aspect Oriented Programming is fascinating. Ruby on Rails is cool if you've never seen it. If you want a challenge, try writing about programming and see how fast you find you HAVE to ramp up. Thing is, once you see something, you have to use it to become an expert. Also, be clear about what an expert is! As a novice you are still learning "What" as in what to do. As a practitioner, you'll know "How" as in how to do it (just about every time). But if you want to be a true expert, it will be about "Who" as in who should the community look to as a thought leader - if you are an expert the answer will be YOU. Be warned, a lot of practitioners AND novices will try to claim to be experts, but ask them about the articles they've written or who exactly reveres them as an expert... Also, lots of this has to be done on your own time if you are not willing to go out and get THE JOB for you. And honestly, if you are not willing to do that, how likely are you to spend your own time getting to "The Next Level" anyway?
1) Be humble.
2) Practice, practice, practice.
3) Learn as many programming paradigms as you can stand.
4) Stop writing programs, start writing libraries and frameworks (and tool kits).
5) Learn to write programs that write programs.
6) Some quick reading on AI doesn't hurt.
7) Know your tool set! Only then will you be able to use it effectively and also its limits.
8) Understand data, data modeling and relational databases. Without data, programs are useless (and even a mouse click is data).
9) Understand what OO really is and use it (hint, it is a lot more than just packaging up operations with data).
10) Learn compilers.
11) A little abstract algebra doesn't hurt.
12) Find the most capable programmers in your area and try to either work with them or hang out with them. The best way to learn is by good example.
If you do this you will find in a few years that you will be no longer writing 'COBOL in drag'.
putting the 'B' in LGBTQ+
Find something that utilizes your desired skills as a project for an off-ours hobby, coding a game, improving some website you runm, etc. Make sure it hit on the next level challenges you are going for. (it does not have to be grand to start, just somehting you think you can accomplish)
Then do it. You only get some knowldge of the concept reading books and artricles, but you won't be skilled at anytrhing it until you do it yourself.
And if you pick a project or it leads to something you haven't seen done elsewhere or not as well as you can envision it, who knows, down the road you may have created the next youtube or myspace.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
I think that attitude is actually the #3 Nerd. I've noticed that sometimes nice and elegant equals overengineered. Sometimes it's good to have non-elegant code to maintain readability. Ever notice when you get the code wonderfully elegant, but it's really saving anything? It doesn't perform better. It's not more flexible(takes as much or more time to modify). Rather than typing two pages of code, it's only half a page(big deal). It takes longer to write because you actually have to think about it. You just have to realize when your awesome generalized functions or recursive masterpiece is overengineered for your little form based frontend to the database.
Some of the language certification tests will push you. One of the things about working on the job is even a crummy company will usually put rules into place that prevent you from doing really ugly things. I mean, "__$_" is a perfectly valid variable name in Java, but I've never known anyone with enough brass to try and push something like that through a code review. Anyhow, I found the Java certification (and a C++ one back in the day) really pushed my understanding of the language itself. Worth doing, if you are looking to hone some skills and not just trying the bare minimum needed to pass a test.
The other thing is to mentor an intern or junior programmer. Few things will push you to 'do things right' more than being an example for others to emulate.
+++ UGUCAUCGUAUUUCU
Lisp is fun to play around with, but Paul Graham's Viaweb wasn't aquired by Yahoo because of it. The idea behind Viaweb was new, and during the dot-com bubble it didn't matter if you wrote in C, Lisp or punch-card machine code: you'd make insane amounts of venture capital anyway.
This sig is intentionally left blank
For about a year I had "The C++ Programming Language" book by Stroustrup, but only used it for reference. Then when I had some free time, I got the idea of doing the problems in the end of each chapter. Not just the easy or hard problems... all of them.
;)
What I found out was a lot of problems that I thought were trivial, weren't. It really forced me to push ahead, learn STL and the Zen of pointers. The few times I got stuck, I'd send an e-mail to a few other geeky developers (like me) on my work team the next day at lunch, and had a good time trying to solve what appeared to be a simple problem.
I found that at the end of a few weeks of going through the first few chapters, I just "knew" STL and C++ that much better.
So my recommendation:
1. Find a good book that ranked well in your area of interest
2. Be sure the book has a set of solve-your-own problems at the end of them
3. Solve them
What are you describing is not elegant, at least, Dijkstra once said that elegant = simple + efficient. Oh yes, I consider myself an artisan trying to craft elegant code :-)
There are situations where a brute-force solution is more practical than an elegantly-crafted solution. However, from what I've seen, software development has been a steady parade of "brute force uber alles" decisions, resulting in hardware requirements continually ratcheting higher and higher in order to run the code as fast as the previous version, because someone decided that it was an earth-shatteringly necessary program enhancement that the drop-down lists animated their expansion when you clicked on them instead of just BITBLTing the entire drop-down area onto the screen at once. As the virtual memory space available to programs has grown, the amount of care that programmers take to write efficient code seems to have gone down. Faster machines conceal sloppy, less-efficient code, and more memory conceals bloated, space-wasting code; whether this is a case of not being taught to write tight code, or accumulated sloppiness from not having to write tight code, I don't know.
At a previous job, I remember looking at one source file from a program that a contractor was developing for us; in each of two dozen functions in the file, they had the same data structure defined local to that function -- a 1000-element array of a structure with about a dozen numeric fields and four 256-character text fields. None of the functions in the file used the text fields in the structure; the structure had been copied from another file where a function did use the text fields, even though the functions didn't actually pass that structure between them; the data was read out of a database in each function. Even more entertaining was the fact that the first time we tested their code on real data, the function that did use the text fields in the structure cheerfully filled the staticly-size 1000-element array with the 2315 rows of data from our database, stomped all over itself because they hadn't put in any bounds checking, and crashed. My code, in a separate program that referenced the same data, used a linked-list module I'd written so that I didn't have to worry about whether I'd made the arrays big enough, and only allocated storage that was actually needed for the database content. I found out later that, after we'd turned the locally-developed code over to the contractor for maintenance support, that they went through and rewrote all my code to use fixed-length arrays, and had an ongoing failure problem due to the real-world data being bigger than the arrays they'd hard-coded into the software, making them go back and rebuild their code each time they got a crash report from the users. Made me wonder how they managed to stay in business with programmers like that.
If you are a C++ programmer, I suggest reading Exceptional C++ and the other books in that series and the corresponding Guru of the Week archive. You can know a lot of C++ and not know much of what's in there. I found I had a much deeper understanding of C++ by reading it and my coding style has changed (for the better, I hope) as a result.
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.
I've noticed that sometimes nice and elegant equals overengineered.
You hippy.
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.
Read. It's a never-ending race to keep up.
Write programs. It's just like how you get to Carnegie Hall - practice, practice, practice.
Learn some more math. Every once in a while a seemingly daunting programming problem will suddenly have a simple and elegant solution just because you happened to understand some mathematical principle.
Well, here's my advice:
1. Read lots of good and bad code, and understand how it fits into a system. Occasionally, you see code from great programmers that is stupidly overengineered with abstract types representing every tiny little object, and the code is very hard to follow.
Good code should be clear and concise.
2. Write code for maintenance programmers. For big systems, you almost certainly won't be maintaining the code. Some other guy (or gal) will. Write the code for them to understand. Keep it simple, commented and clear.
3. Code often goes through design iterations. Write the simplest code that can work efficiently. Use an appropriate data structure. Minimize temporary object creation etc.
4. Learn a functional language. This gives a new viewpoint that can be useful, though it's a slow way to learn memoization, which may be the most useful thing ever.
5. Don't be afraid to refactor. Most of the good code in the world didn't look that great when it was first written.
Good luck!!
-- "It's not stalking if you're married!" My Wife.
It may sound Philistine, but I think one of the very best ways to get better at something is to do it under pressure. With programming, having a smart mentor nearby can be a tremendous help in such a situation, but even working alone under pressure will both (1) improve your understanding, and (2) stretch your capacity (endurance, memory, etc).
That pressure can come from either an external deadline or, if you are able to do it, an internal one (more difficult to achieve, IMO). Programming contests may be a really good place to find them: you get all three: (1) interesting, difficult problems, (2) time pressure, and (3) smart mentors (well, only partially, since you can only get advice by viewing others' code after the fact).
As long as you get enough sleep, that is :)
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.
How do you know it is really a compiler bug until you look at the compiler output?
You can guess by saying with certain options, the program works, and with other options the program fails. But,you cannot be sure until you read the code.
What you said about rewriting code to avoid the problem reminded me of when I had a bug with Masm which would not do proper offsets with structures, so I changed the order of the structure so it would not matter. The problem is that before you change the code (or compiler options) you should know the problem, not just guess it.
Fight Spammers!
I try to write tools that will make my and my co-worker's lives easier. I usually end up learning a few things along the way. Plus I end up with a time saving utility.
Coder's Stone: The programming language quick ref for iPad
Viaweb wasn't the only player. There were several others. Viaweb was aquired by yahoo because it was the best. It was the best because they were using a productive language (lisp in this case, but it doesn't have to be lisp) instead of an "industry best practices" language like their C++ using competition. So while yahoo didn't say "oh sweet, its a lisp app, we better buy them", lisp was indirectly the reason yahoo bought them.
grandparent is correct.
learn how to do metaprogramming. learn how to write operating systems, compilers,
and design languages. then when you have to do some random server-side crap, you
can do it less time, with greater extensibility and stability, and have more
fun doing it.
or you can spend the rest of your life spitting out the same little balls of
php.
They say that you can't be a great writer unless and until you've done close readings of great works of literature.
Similarly, it's extremely elightening to do close readings of source code of software projects you consider "great". Pick a "great" (or even not-so-great) software project for which you have access to the source code. Download the source. Then, do a close reading of the source. Understand how the software works, control flow, data organization, class heirarchies, etc., even the build system.
You might decide that in the end that it's crap, but you'll never know until you read it. But it does provide a good method for learning a lot about how software is put together. Many (but not all) open-source projects are very close to doing best practices due to the collective nature of the development.
In the course of every project, it will become necessary to shoot the scientists and begin production.
1) Use downtime at work as a chance to learn. Since you're stuck there anyways, grab an sdk that interests you and plug away. Your boss would probably like it better if he/she saw an IDE open on your desktop, not myspace.
;)
2) Get another hobby. Juggling two hobbys will help you value your time more. I rarely do any programming at home mostly because I'd much rather be doing something else. Granted I have lots of downtime at work, I try to do some hobby-coding while I'm there.
Which brings up a question, is hobby-coding at work bad during downtime? I downloaded the DirectX SDK and I'm teaching myself a little game programming. I don't see this as an issue if this doesn't interfere with my work. It actually keeps me off the net and makes the day go much faster. Although, I'm a government employee
There's a pretty interesting article posted on Computerworld's site today that details why it's increasingly difficult to find solid IT jobs even though more and more companies are preparing to hire. http://www.itworldcanada.com/a/IT-Workplace/dc4b99 1d-1d3b-4c26-ae56-3bb84c0faf9f.html
Dude, check out Extreme Programming! That will let you take your skillz TO THE MAX!!
Programming in a group outside of work on a GAME. Simple things with simple features with hard basics. A MUD.. a strong mud is fun and you get the whole cornacopia of techniques from hash tables, jump tables, file functions, sockets, performance and other issues.
Make a Game online and find out how fast you improve.
My problem is not work is not challenging.. is that its very challenging and a MUD is a way to relax code and learn without having to learn under power pressure.
www.mageslair.net
I can program myself out of a Hello World Contest!!
Goto sf.net and look through projects. See if you might be able to help out in an active project that lies outside your typical knowledge base.
In college you probably learned a lot of the concepts that many projects rely on, but in order to increase your skills you have to branch out from the day to day. If you're using the same languages and spending long stretches working on the same projects (for work or whatever) you're not going to expand your technique very much.
To get stronger you have to build more muscle, building more muscle requires lifting heavier weights.
No sig for you!!
I'm a fledgling programmer looking for advice on how to take my programming skills to the next level. I've read Petzold's programming in the key of c#, and teach yourself ruby in 21 days. I've taken the "advanced java" course (and all the programming classes for that matter) at the local community college, but I feel like I've missed out on anything vaguely complicated. advanced java was all jsp stuff interacting w/databases, and the other classes didn't really do anything for me(they tried, but how many times can you write hello world?). What would be the next steps you all recommend for someone who wants to learn programming, is willing to set aside time to do so, but does tech support full time so isn't given programming type tasks at work?
Your sig(k) has been stolen. There is a puff of smoke!
If I may, perhaps volunteer to assist an open-source project.
Try to find a project that is of interest to you, and is using modern techniques, environment, languages, etc.
Uh, Linux geek since 1999.
I feel that my programming skills haven't really progressed to the next level as I had hoped
One poster suggested facetiously to try going down a level. However, there is merit in this suggestion. Try going back to something more basic than programming. Go deeper into the math, the algorithms, the machine architecture. These are the things that a CS degrees prepares you do and they should give you insights into problem solving that programming cannot.
For most programmers, progress is quantitative. The more they know, the more they can do. They may not be better programmers but they are better employees. Many of us understand that while there is no limit to how much we can learn, there is a limit to how good we can get. You may have simply reached that limit. Now, you have to settle in for a lifetime of typing code (not as bad a fate as you might think), or take a step back and revisit the fundamentals.
If you don't find inspiration there, maybe you should be looking outside the profession altogether.
Join a project that seems like a challenging topic. You will learn so much more... sourforge.net has tons to join. I thought I knew alot about programming but its different to actually be part of a project which you are unfamiliar with. Try to find a project written with a diff language, you'll learn more.
Hi, I'd definitely recommend the Pragmatic Programmer http://www.amazon.com/Pragmatic-Programmer-Journey man-Master/dp/020161622X/sr=1-1/qid=1161902709/ref =sr_1_1/104-0184310-1779920?ie=UTF8&s=books
It's a great book and really well written, by the time you've finished not only will you be full of useful knowledge, but you'll be raring to use it.
I'd also recommend the Write Great Code series especially this one, Thinking Low Level, Writing High Level, http://www.amazon.com/Write-Great-Code-Low-Level-H igh-Level/dp/1593270658/sr=1-1/qid=1161903244/ref= sr_1_1/104-0184310-1779920?ie=UTF8&s=books this book really opens your eyes about what your code is doing.
Enjoy!
Dum spiro spero
if the following apply to you:
* you are sometimes excited about programming
* you like games
* you are a creative person
* you have 2 days to spare
then go participate in one of the 48hrs game development contests or pyweek or something.
Four years ago I started a project at home in order to flex my programming muscles in new technologies. The project was to build a home network, media centre, home automataion, etc. Build my own "smart house" essentially with an English interface, speech, PDA, and a bunch of other ways me and mine could control the house, our entertainment and orgaise our lives.
Now I have six PCs spread across the house with a fast network, permanent net connection and a family of cherubs that use this stuff everyday. So in thtat sense its been very practicial as our lives have been transformed from the sheer ease with which we now live.
The technology benefit: I've had to build my own boxes, install o/s and configure the network. I've customed built a two linux boxes, a media centre, and added other hardware. I've had to custom write a control system, media catalog and allow it to be fully distributed both externally and at home accessible from any box (or even from work through proxies) and have faced problems that your not going to face any other way. Whilst I've written most of it in Java I've had to spread into a diverse range of Java technologies, hook into MS Outlook and other .NET stuff, interface with Winamp, and other media players. I've even hooked up a remote dialler, linked to an SMS gateway and have caller ID installed. At one stage I was plowing through the ID2 spec to read MP3 tags and then jumped onto the RIFF spec to catalog AVIs. Deep stuff.
In short, a bucket-load of technologies, both hardware and software, that I would never, ever, get my hands on in my professional roles. I've faced a myraid of difficult problems, spent lots of late nights arguing with the thing, and shouted loudly. I have learnt an immense shit-load in a variety of tools and specialities. The project (Blade, see my URL) comes up n every interview lately with much discussion on the technologies that I've had to learn. Its proudly on my resume.
The best bit is that whilst learning I've built something that benefits me and my family immensly, which is always a proven motivator. Much more motivating than learning something because its your job. And the scale of the project will keep me learning and adapting for the next coupe of decades.
Best of all - my wife and kids are proud of me :-) Shucks.
Rick
We do not inherit the Earth from our parents. We borrow it from our children.
No matter how inane your idea, start a project online. Submit it to various places like BetaNews. Learn how to deal with front line programming - you will find each day is a new challenge. I've learnt an incredible amount from silly projects. Case in point would be a little backup app I wrote. I had to learn about living in the system tray, playing nice with computer shutdown events, and a million other little things I never thought of at the outset.
In short as many other people are saying: practice makes perfect. In my opinion, putting yourself out there is important because the stupidity of users and the obscurity of their feature requests makes you go outside your comfort zone. Programming to suit your own needs won't provide the same level of motivation for learning.
As for learning a new language, I've always been able to pick them up as needed. Learning a new language probably won't give you the same thrill as going deeper than you have before with one you know.
It's OK Bender, there's no such thing as 2.
I think this would make for an interesting /. poll. Especially if people started to post things like what OSes, programming languages, and IDEs they use. I'm definitely a hippie myself.
Your CPU is not doing anything else, at least do something.
If noone you work with knows more than you, they can't teach you much. If you work with people that know more than you, they can teach you tremendous amounts. Take advantage of that. Learn all you can from them. When you know as much or more than they do, find a new job with people who know more than you. Many people are intimidated by working with people more knowledgable than them. Don't be. It's really not all that different from your formal education. You just get paid for it :)
Learn assembly language and write a simple app like rudimentary text editor or line-art drawing tool, something that requires most of the basic IO functions. (Then try an application launching menu - yay memory management! :)
.asm code, you understand what is really going on at the machine level. That knowledge will allow you to grow beyond being a VB coder (the modern equivalent of a the old COBOL coder) who can't do much except slap together classes (modules) that some real programmer designed, wrote and tested.
I agree with what you said, but am going to explain why it helps to be good at one (or several) assembly languages.
If you can write I/O routines and convert the sort of algorithms needed to write a text editor into
"You're young, you're drunk, you're in bed, you have knives; shit happens." -- Angelina Jolie
.. learn Common Lisp.
I sort of agree and disagree with you and the GP.
/. comment will help you there.
First, Lisp is a better language, it has concepts yet to be discovered in most other languages, but you have to study the language and code non trivial examples to grok that, no book or
Second, C++ and PHP are not fads. I can tell that because have used both C++ and PHP since long before I had learned Lisp. Also, C++ and PHP are the ones that give me money, something Lisp has not done yet.
But just last week I was really hoping that PHP had closures and first order functions, as that would have made my job much easier. In fact, that sensation of "well I feel like trapped in this language" is real but anyway it doesn't matter.
Why? because you can code anything in any language. Sometimes what is trivial in Lisp requires a mini-parser in other languages, that is, a little more coding. Or some other technique. but it's equally doable and it doesn't matter what language I use, I still code much faster than my co-workers. And I get things done.
But in direct response to your post, well those academics have a point. Better languages can really give better solutions. However, the bad news are: Lisp stopped evolving a long time ago, with a small rebirth because of P. Graham since about 3 years, but still lacks a good free windows implementation to get all those programers that could need it. Yes, MSWindows is important, as finally PostgreSQL developers discovered, a little late after MySQL had almost all the marketshare. Otherwise USD$2000 is too expensive for a programming language license, if you have to choose between C# or Java and Lisp.
My point? There is a good oportunity to bring a nice GUI enabled BSD licensed version of Lisp for MSWindows (multiplatform would be better) and I would jump to it in a second if it existed.
(Note to lisp zealots: wxCL doesn't cut it, as it simply doesn't compile in my box. And most Lisp implementations are GPL or LGPL and they infect my code. LGLP infects code when linking statically which simply misses the point of ECL. I'm waiting for SBCL on MSWindows. The SBCL license is a good one.)
We are Turing O-Machines. The Oracle is out there.
Pick a favorite language, and just code for fun. The skills will come later.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
HI I was in the same situation programming/maintaining Unix Server/Clients in the financial industry for about 5 years. After few years I wanted to learn more skills. I fancied giving training in programing so I got a job doing just that. After three years, I joind a vendor doing mobile phone operating system as software enginer (debugger/tester). during which, I used to hear a lot of horror stories about support in the software industry. I fancied doing that so I joined a vendor for real time operating system as technical support engineer level 2 and 3. I liked it so much that I stayed there for about 7 years. It was the most challenging aspect of my career. the interactionwiht other software engineers formoutside the company was incredible and a mine of learning. Few months ago I wanted more challenging job, and thats when I was transferred as a senior enigner in the professional services department. This is the ultimate challenge for me. The ability to take on projects at very short notice about a subject you vaguely know and be able to deliver on time. So now I am on the road and work from home :-) and travelling the world. The pressure is intense and can be very stressful.
So I spanned Software engineering, training, technical support and back to software engineering. Todo all these jobs I have accumulated a large library that beats my local IT library.
My advice is to read a lot of books specially about algorithm and patterns, operating systems. I don't know about languages but I am sticking to C/C++ and Java. I don't write much programs in my spare time (I have to protect my marriage) except when I write some samll utilities using Java mobile for phones and PDA, nothing big just small useful utilities.
I would say the technical support engineer (level 2 and 3) gave me the most experience as I had to learn the internal of the operating system and that knowledge was a tremendous learning experience.
Now I am aiming to be a consultant. Amazing after all that I am still happily married :-)
Cheers
This entire thread is strange to me. I am a musician that funds my hobby by working in computers. I am by no means a master programmer or even terribly proficient. I tend to take on personal projects that need to be completed but that real programmers don't have time to do. I tend to do them with whatever tool seems to be the easiest to do it with. I don't have a CS degree. I don't know a lot of theory; however, every time I take a little project on it gives me a little bit of experience (and often a little piece of re-usable code) and I get better and better at writing clean, useful, and reusable code.
This thread is strange to me because so many people on here are telling this guy what not to do as if there is a right or wrong way to learn to program instead of offering suggestions. The way I learn is not going to get an operating system written; however, for every one of me there is some guy out there who wants to write his own operating system and is interested in what I find tedious. I guess if I were to compare it to something I would compare it to songwriting. What is the best way to write a song? Some people write songs following a formula or self-imposed or stylistic goal. Some people learn a ton of theory and then try to find new and exciting ways to execute it. Some people write some words about how they hate their girlfriend and then bash a guitar so they can get a new girlfriend with more enhanced breasts. All of them are valid and all of them accomplish exactly what was intended [some with more assistance from alcohol than others]. The trick is in identifying what you want to accomplish and then finding proper motivation to achieve whatever it is you set as a goal.
Believe it or not, not everyone in the world is the same. Different people want to do different things. What is wrong for one guy is bomb for another. Bagging on languages and platforms is just as stupid as saying Steve Vai is a better guitar player than Hendrix because he's more precise or because he can read music and transcribe insanely complex Zappa songs for guitar. If you ask a different person they'll tell you that Vai has no soul and Hendrix is the definition of it. Just because I think Steve Vai sounds like someone playing scales really fast doesn't mean it is wrong; it just means that I don't get it. It doesn't inspire me. If someone's idea of a kick ass time involves spending months learning the deep inner workings of how code is executed on a computer and accomplishes it by learning how to write a bunch of assembly which they then give away for free, more power to them. If someone else just wants to turn a bunch of xmls generated by some time tracking software into a csv formatted file that their stupid corporate oracle itime software can ingest so they don't have to duplicate work every friday before they go home to play rock music in their band, that's a good time too... for at least one guy I know. Talking smack on either one, however though provoking it may end up being, is usually counter-productive.
Ghostunit said a few things I disagree with because I don't think telling people what not to do is very useful in this case. What he said at the end though is money. Find something interesting and you won't be able to help but get better as you work on it. The instant you get it done you'll have thought of 10 ways to do it better or faster and those lessons will apply to the feature creep that your little project will undoubtedly get after your coworkers see what you've done and ask you to bolt stuff onto it. You'll do that and build an entirely useful tool which your company will then own because of an agreement you signed when you got hired. They will sell it for millions and then give you a raise that doesn't keep up with inflation. Regardless, you'll get better at writing code which is the point of this whole spiel. If that doesn't sound appealing to you, you can try out some of the other suggestions. You can learn to write something in assembly or lisp if that's what turn
Do you mean a better programmer as in, better at doing harder problems, or just being more experienced. Look here http://www.inf.bme.hu/contests/tasks/ for interesting and pretty difficult problems