Large companies typically have manuals. Sometimes the manuals are hard to find. Or, there are so many that you can't figure out which ones are important or up-to-date. But usually it is not so difficult. They are ofen found in your manager's cubicle, or on the company intranet. If you read them, you'll gain amazing insights.
They might be business books, such as something by Geoffrey Moore. If you read them, and quote them every now and then when appropriate, you will get strange looks, but you will be considered to be a player.
The general practice of manual-reading also works in other domains. Once you get used to it, you will find that it is a great 'secret-weapon'. Don't spend time at work reading the manuals except to look something up - this prevents you from casting the illusion that you are always doing 'real work'. Take them home, read them, or at least look through them to understand what is covered on every page, and then bring them back. Expect to spend something like five to ten hours a week on this.
There are also amusing books such as "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis" that are better than just reading Dilbert.
I chose the technical path when I was your age 11 years ago. No regrets - but I am a veins-in-the-teeth competitive programmer.
If you want to get into management, it is much better if you get to create your team.
You interview everyone, they understand that you hired them, they work for you, and they will do what it takes to make the project a success.
If you take up management of an existing team, then you're just another PHB, and the team might be damaged goods. Probably not worth the risk.
Since you are in a toss-up situation, only select management if you get to choose the team. Sometimes this is negotiable.
My Make: articles had schematics and circuit explanations. It was difficult to get the schematic graphics to properly scale using vectors instead of bitmaps. I used Open Office for the schematics in This Old Amp, and the magazine's production path kept mangling the vectors. I got better results after I switched to Adobe Illustrator.
The makezine.com site has a some of the detailed design information that is missing from the magazine. Authors are encouraged to put anything on the web site that was left out of the print article.
I happen to know a guy that developed code to translate a stack of papers from a mortgage closing into a nice neat database row so the bank can sell a mortgage to some far away bank.
I met him at a local Perl Mongers meeting, but he switched from Perl to Java for this code in the late 1990s. His reason was because at the time Java had better support for XML, especially for entities.
Based on what he told me he was doing, I expected a mortgage disaster like this for years - it finally happened.
The one on the right has a flat head and the bottom of her ears are cut off. If you saw the one on the right from a different angle, she would look messed up, or would need a different transformation. The one on the left would look much better in real life, because when she turns her head a little bit, it wouldn't ruin her looks.
No, I can't make a job offer in a Slashdot reply.
To make collaborative CAD tools, build on one of the Open Source efforts, such as http://geda.seul.org/.
Maybe I'm missing something, but if you are asking for work, a potential employer would need to know how to get in touch with you. This would preferably not involve replying to a slashdot article.
Collaborative CAD tools such as you describe already exist, but there is plenty of room for improvement.
Slashdot Mirror
Large companies typically have manuals. Sometimes the manuals are hard to find. Or, there are so many that you can't figure out which ones are important or up-to-date. But usually it is not so difficult. They are ofen found in your manager's cubicle, or on the company intranet. If you read them, you'll gain amazing insights.
They might be business books, such as something by Geoffrey Moore. If you read them, and quote them every now and then when appropriate, you will get strange looks, but you will be considered to be a player.
The general practice of manual-reading also works in other domains. Once you get used to it, you will find that it is a great 'secret-weapon'. Don't spend time at work reading the manuals except to look something up - this prevents you from casting the illusion that you are always doing 'real work'. Take them home, read them, or at least look through them to understand what is covered on every page, and then bring them back. Expect to spend something like five to ten hours a week on this.
There are also amusing books such as "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis" that are better than just reading Dilbert.
I chose the technical path when I was your age 11 years ago. No regrets - but I am a veins-in-the-teeth competitive programmer. If you want to get into management, it is much better if you get to create your team. You interview everyone, they understand that you hired them, they work for you, and they will do what it takes to make the project a success. If you take up management of an existing team, then you're just another PHB, and the team might be damaged goods. Probably not worth the risk. Since you are in a toss-up situation, only select management if you get to choose the team. Sometimes this is negotiable.
The makezine.com site has a some of the detailed design information that is missing from the magazine. Authors are encouraged to put anything on the web site that was left out of the print article.
Science in Make is ambient - it doesn't hit you over the head.
My attempt to encourage science is the Open Source Hardware <Shameless-plug> High-Speed Photography Kit Version 4</Shameless-plug>
It's nothing you can't build yourself.
I met him at a local Perl Mongers meeting, but he switched from Perl to Java for this code in the late 1990s. His reason was because at the time Java had better support for XML, especially for entities.
Based on what he told me he was doing, I expected a mortgage disaster like this for years - it finally happened.
The one on the right has a flat head and the bottom of her ears are cut off. If you saw the one on the right from a different angle, she would look messed up, or would need a different transformation. The one on the left would look much better in real life, because when she turns her head a little bit, it wouldn't ruin her looks.
No, I can't make a job offer in a Slashdot reply. To make collaborative CAD tools, build on one of the Open Source efforts, such as http://geda.seul.org/.
Maybe I'm missing something, but if you are asking for work, a potential employer would need to know how to get in touch with you. This would preferably not involve replying to a slashdot article.
Collaborative CAD tools such as you describe already exist, but there is plenty of room for improvement.