If you are really trying to get to an "intermediate" level you could start doing simple data structures and algorithms. Learn the classic sorting routines, linked lists, etc. Once you understand those you can start seeing how they are used in large programs. Look at some of the annotated programs -- the Lion's book on Unix is a good collection of readings to see how an operating system is structured for example. Games are a great way to develop your skills but you may not have enough background yet to get very far. Read the Python source code - you may not understand all of it but you will learn how a language interpreter is put together.
Welcome to a long and twisty path as a programmer. Something new to learn every day.
Old Joke: "What do they do with Engineers when they turn 40?" A: Buy them a birthday cake then take them out to the parking lot and shoot them.
18 years of experience probably means you are either getting close to your 2nd cycle of becoming an "expert" in a technology area or you've been doing the same 2 years work 9 times in a row. Either way, it's time to get out of your current sweet spot and learning something entirely new. You need to get "leverage" with your experience. Really learn something like Agile Processes, Project Management, Finance, a critical business area, requirements management, Continuous Integration/deployment tools, DevOps, etc. Don't try to recreate the same old skills in a new programming language -- it's a dead end.
Me? I started programming 40 years ago in high school and have over 30 years industry experience. I've tried to learn something new every 18 months and have managed to survive so far.
Good luck, the next 10 years of your career can either be the best decade or the hardest depending on how flexible you are.
You could always look into a digital design or graphics design curriculum. Some of the better art schools are lightyears ahead of the computer sci schools in teaching ways to really use the web and digital media.
I can see them off-shoring production to China and getting 100's a month. Their big problem is going to be training pilots fast enough.
As far as the "age" - it was a good design then and is still a good design. Upgrade the weapons to something more modern and they are going to be very dangerous on a battlefield.
Put together a very detailed checklist of everything you are going to hand off. Make him own the list and take notes then make him do a review with you and his manager of what he's learned and then have both of them sign off on the training. Be available for quick questions but keep very detailed notes about how much time you are spending during the first couple of weeks. When he calls you should ask what he's done already with the problem to make sure he isn't getting into the default behavior of calling you first. You need to make sure he can be successful (as in the don't burn bridges philosophy) but at the same time is taking ownership of the job.
If you continue to present yourself as a "programmer" you will continue to get programming assignments. What sort of projects are you good at? What types of problems can you solve? Think of yourself as a business instead of as an 'employee'. The old "You Weren't Meant to Have A Boss" mindset (see: http://www.paulgraham.com/boss.html ).
Get out there and do something cool, don't sit around waiting for someone to tell you what to do!
This could end up in the same museum as "No one will ever want a computer in their house" (Ken Olsen), "The world only needs 7 computers", and "640K memory will always be enough". It's a bad idea to make long-term generalizations based on the first release of a new form factor.
It looks like someone at the Times made a mistake.
I just received this from NYTimes: "Dear New York Times Reader, You may have received an e-mail today from The New York Times with the subject line “Important information regarding your subscription." This e-mail was sent by us in error. Please disregard the message. We apologize for any confusion this may have caused. Sincerely, The New York Times"
Welcome to a whole new world. Get Michael Lopp's "Managing Humans", start thinking about the business value of what you are doing instead of just the technology, and at some point you may want to read Peter Senge's "The Fifth Discipline". You have 3 priorities you need to keep in balance: 1) your financial responsibilities to the company, 2) taking care of your people, and 3) doing the right thing for the customers.
Beware: If all you can do is code there's a great chance your job will end up in India. You have to have broader skills now to be competitive. Instead of taking classes in an area you obviously know well (i.e. coding), why not take more general business classes or in the sciences so you can use your coding skills as a tool to solve critical problems rather than being a coder waiting for a problem to get assigned to you? 99% of the people you will need to work with aren't coders and if you don't have any general skills you won't be able to work with them as effectively.
Agreed. It isn't meant for raw beginners but it is still the best reference for the language and essential for a hard core C++ programmer to have as a reference.
Thanks for adding the Lippman Object Model book. Another very worthwhile book to have if someone wants to be a real C++ guru.
I would recommend the following books: Alexandrescu - "Modern C++ Design: Generic Programming and Design Patterns Applied" Meyers - "Effective C++" and "More Effective C++" Stroustrup "The C++ Programming Language" Stepanov - "Elements of Programming" Koenig - "Accelerated C++" Koenig - "Ruminations on C++" (A little out of date but still a good read)
Good luck, C++ has evolved into a large and complex language. You may want to read Stroustrups "The Design and Evolution of C++" on the side to understand how it developed.
The Technical School will help you get your first job, the Liberal Arts education will help you long after you have to write code, especially if you want to move into management later on.
The "only 5.5 MPH" difference huge. That's about 4 seconds a lap which means that over a 500 mile race on a 2.5 mile track, the 1st place car will lap the 31st place car 5 times. When you factor in driver ability, strategy and pitstops, the difference will be much greater. The top 3 cars in the race will probably be within.25 second of each other after 500 miles.
In general, the cars are much slower now than they used to be. The 225.817MPH of the 1st place car would have been very far back in the grid compared with the 240 MPH+ of 10 or 15 years ago. I wish him luck.
The first Internet Worm (aka "Morris Worm", 20 years ago this year) used a hole in BSD Unix and Sendmail. It was taking advantage of the fact that BSD Unixs were the standard (SUN OS and Ultrix) in the research communities. Other OS' like VMS, MVS, Guardian, VOS, etc were not as hackable.
Unix basically invented the internet security hole. They've just had longer to patch them than the Windows world.
The technical data you learn in a certificate program has a half-life of about 18 months. That's when you will have to learn something new. The generic skills you get from a good university program will be useful for the rest of your life. The first 2-4 years are purely about your technical skills, the next 30+ will be about your ability to interact with people, communicate, and learn. The lack of a university degree will make any upward mobility 10 times harder.
To expect a "box" to be secure by itself is unrealistic. How do we build a security "System" around electronic voting to make the end-to-end process reduce the probability of security breaches to a minimum? What are the expectations about storing the equipment between use, testing them prior to each use, managing the inevitable software upgrade cycle, etc?
1. Plan on studying something new every 12-18 months. 2. Don't just concentrate on technologies. Study Project Management, Emotional
Maturity, Presentation skills and public speaking. Think of yourself as an
investment, you want to hedge your down-side by making sure you have skills
completely outside the particular situation you are in at any given time. 3. Review yourself every 6 months or so. Are you stuck in a learning rut, continuing to
read the same types of junky "Visual Basic in 21 nanoseconds" or are you actually
challenging yourself? 4. Review the basics every so often. Go back and read a deep book on analysis of
algorithms or databases or language design. 5. Try to push yourself out of your comfort zone every few years. 6. Don't get too hung-up on the buzz-word du jure. 90% of them will last a millisecond
in your career. 7. Treat everyone you come into contact with as a teacher.
1. make sure you really understand the fundamentals of computer science. once you get the foundations really captured you will be able to learn a new technology pretty quickly.
2. don't make the mistake of believing that your technical skills will keep you employeed. as important as they are they are only about 30% of what you need on a daily basis to survive.
3. instead of doing "toy" problems to learn a language or an api, try doing an "end-to-end" project. write user requirements, do a detailed design, code, write formal test cases, use a configuration management system.
4. start defining your "personal process". use something like the SEI's Personal Software Process model.
Slashdot Mirror
If Midtown Atlanta made the top 10 list for walkability you need to check your math.
All companies are Information companies now. Any job that you can get will require some minimal knowledge of how to use a computer.
If you are really trying to get to an "intermediate" level you could start doing simple data structures and algorithms. Learn the classic sorting routines, linked lists, etc. Once you understand those you can start seeing how they are used in large programs. Look at some of the annotated programs -- the Lion's book on Unix is a good collection of readings to see how an operating system is structured for example. Games are a great way to develop your skills but you may not have enough background yet to get very far. Read the Python source code - you may not understand all of it but you will learn how a language interpreter is put together.
Welcome to a long and twisty path as a programmer. Something new to learn every day.
Old Joke: "What do they do with Engineers when they turn 40?" A: Buy them a birthday cake then take them out to the parking lot and shoot them.
18 years of experience probably means you are either getting close to your 2nd cycle of becoming an "expert" in a technology area or you've been doing the same 2 years work 9 times in a row. Either way, it's time to get out of your current sweet spot and learning something entirely new. You need to get "leverage" with your experience. Really learn something like Agile Processes, Project Management, Finance, a critical business area, requirements management, Continuous Integration/deployment tools, DevOps, etc. Don't try to recreate the same old skills in a new programming language -- it's a dead end.
Me? I started programming 40 years ago in high school and have over 30 years industry experience. I've tried to learn something new every 18 months and have managed to survive so far.
Good luck, the next 10 years of your career can either be the best decade or the hardest depending on how flexible you are.
You could always look into a digital design or graphics design curriculum. Some of the better art schools are lightyears ahead of the computer sci schools in teaching ways to really use the web and digital media.
Good luck,
Plant a tree,
Rescue an abandoned pet
Help kids,
Be a person your Grandmother would respect.
My thought exactly. You could go through the entire series then get him started on some of the short stories.
I can see them off-shoring production to China and getting 100's a month. Their big problem is going to be training pilots fast enough.
As far as the "age" - it was a good design then and is still a good design. Upgrade the weapons to something more modern and they are going to be very dangerous on a battlefield.
All of the early Robert Heinlein are fun. Lots of great stuff out there.
-c
Put together a very detailed checklist of everything you are going to hand off. Make him own the list and take notes then make him do a review with you and his manager of what he's learned and then have both of them sign off on the training. Be available for quick questions but keep very detailed notes about how much time you are spending during the first couple of weeks. When he calls you should ask what he's done already with the problem to make sure he isn't getting into the default behavior of calling you first. You need to make sure he can be successful (as in the don't burn bridges philosophy) but at the same time is taking ownership of the job.
Good luck,
-c
If you continue to present yourself as a "programmer" you will continue to get programming assignments. What sort of projects are you good at? What types of problems can you solve? Think of yourself as a business instead of as an 'employee'. The old "You Weren't Meant to Have A Boss" mindset (see: http://www.paulgraham.com/boss.html ).
Get out there and do something cool, don't sit around waiting for someone to tell you what to do!
This could end up in the same museum as "No one will ever want a computer in their house" (Ken Olsen), "The world only needs 7 computers", and "640K memory will always be enough". It's a bad idea to make long-term generalizations based on the first release of a new form factor.
It looks like someone at the Times made a mistake.
I just received this from NYTimes:
"Dear New York Times Reader,
You may have received an e-mail today from The New York Times with the subject line “Important information regarding your subscription."
This e-mail was sent by us in error. Please disregard the message. We apologize for any confusion this may have caused.
Sincerely,
The New York Times"
Welcome to a whole new world. Get Michael Lopp's "Managing Humans", start thinking about the business value of what you are doing instead of just the technology, and at some point you may want to read Peter Senge's "The Fifth Discipline". You have 3 priorities you need to keep in balance: 1) your financial responsibilities to the company, 2) taking care of your people, and 3) doing the right thing for the customers.
Good luck,
Beware: If all you can do is code there's a great chance your job will end up in India. You have to have broader skills now to be competitive. Instead of taking classes in an area you obviously know well (i.e. coding), why not take more general business classes or in the sciences so you can use your coding skills as a tool to solve critical problems rather than being a coder waiting for a problem to get assigned to you? 99% of the people you will need to work with aren't coders and if you don't have any general skills you won't be able to work with them as effectively.
Good luck,
-c
Agreed. It isn't meant for raw beginners but it is still the best reference for the language and essential for a hard core C++ programmer to have as a reference.
Thanks for adding the Lippman Object Model book. Another very worthwhile book to have if someone wants to be a real C++ guru.
I would recommend the following books:
Alexandrescu - "Modern C++ Design: Generic Programming and Design Patterns Applied"
Meyers - "Effective C++" and "More Effective C++"
Stroustrup "The C++ Programming Language"
Stepanov - "Elements of Programming"
Koenig - "Accelerated C++"
Koenig - "Ruminations on C++" (A little out of date but still a good read)
Good luck, C++ has evolved into a large and complex language. You may want to read Stroustrups "The Design and Evolution of C++" on the side to understand how it developed.
-c
The Technical School will help you get your first job, the Liberal Arts education will help you long after you have to write code, especially if you want to move into management later on.
Good luck,
The "only 5.5 MPH" difference huge. That's about 4 seconds a lap which means that over a 500 mile race on a 2.5 mile track, the 1st place car will lap the 31st place car 5 times. When you factor in driver ability, strategy and pitstops, the difference will be much greater. The top 3 cars in the race will probably be within .25 second of each other after 500 miles.
In general, the cars are much slower now than they used to be. The 225.817MPH of the 1st place car would have been very far back in the grid compared with the 240 MPH+ of 10 or 15 years ago. I wish him luck.
The first Internet Worm (aka "Morris Worm", 20 years ago this year) used a hole in BSD Unix and Sendmail. It was taking advantage of the fact that BSD Unixs were the standard (SUN OS and Ultrix) in the research communities. Other OS' like VMS, MVS, Guardian, VOS, etc were not as hackable.
Unix basically invented the internet security hole. They've just had longer to patch them than the Windows world.
The technical data you learn in a certificate program has a half-life of about 18 months. That's when you will have to learn something new. The generic skills you get from a good university program will be useful for the rest of your life. The first 2-4 years are purely about your technical skills, the next 30+ will be about your ability to interact with people, communicate, and learn. The lack of a university degree will make any upward mobility 10 times harder.
Good Luck,
-c
To expect a "box" to be secure by itself is unrealistic. How do we build a security "System" around electronic voting to make the end-to-end process reduce the probability of security breaches to a minimum? What are the expectations about storing the equipment between use, testing them prior to each use, managing the inevitable software upgrade cycle, etc?
1. Plan on studying something new every 12-18 months.
2. Don't just concentrate on technologies. Study Project Management, Emotional
Maturity, Presentation skills and public speaking. Think of yourself as an
investment, you want to hedge your down-side by making sure you have skills
completely outside the particular situation you are in at any given time.
3. Review yourself every 6 months or so. Are you stuck in a learning rut, continuing to
read the same types of junky "Visual Basic in 21 nanoseconds" or are you actually
challenging yourself?
4. Review the basics every so often. Go back and read a deep book on analysis of
algorithms or databases or language design.
5. Try to push yourself out of your comfort zone every few years.
6. Don't get too hung-up on the buzz-word du jure. 90% of them will last a millisecond
in your career.
7. Treat everyone you come into contact with as a teacher.
1. make sure you really understand the fundamentals of computer science. once you get the foundations really captured you will be able to learn a new technology pretty quickly.
2. don't make the mistake of believing that your technical skills will keep you employeed. as important as they are they are only about 30% of what you need on a daily basis to survive.
3. instead of doing "toy" problems to learn a language or an api, try doing an "end-to-end" project. write user requirements, do a detailed design, code, write formal test cases, use a configuration management system.
4. start defining your "personal process". use something like the SEI's Personal Software Process model.
good luck
I wonder how many of us became engineers at least partially because of him?
"Cap'tn, she can na take any mor!"