My mother despises MacOS and can't "figure anything out." Now while I don't care for MacOS myself...
Now, where's the "some of my best friends are Mac users" snark?
Seriously, the only unhappy Mac user I've ever met was one who was given a new OSX machine to replace a pre-arc Win3.1 box. With no training.
This is the issue - no training. Everything your mother knows about computers is now worthless - you've just devalued her. Naturally, she's pissed.
As the family IT dude I can only re-iterate that I've never met an unhappy Mac user. Sometimes the transition from Win32 is a little painful (my MIL is doing that now) but once it's done I get basically zero "can you have a look" calls from the Mac users. It just works.
Someone once described management as "the art of making and prioritising lists". I'd also add _communicating_ the lists.
The other half of the job is sheilding your management from your team and vv. While ensuring that no-one is suprised - management, team or customer.
Get reading - both dead tree (dynamics of software development, mythical man month, peopleware, dibert) and online (eg. rands in repose).
Start learning "systems engineering" - the NASA systems engineering handbook is available free on line (http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa. gov/19960002194_1996102194.pdf). If you cannot state what it is that you and your team need to do to both be finished and prove that you are finished you are lost.
Systems engineering is sometimes described as "engineering management defined so that MBAs don't do it". For good reason.
Start learning about risk management (AS/NZS 4360:1999) and Earned Value Management Systems. And basic accounting principles (esp. cash flow and ROI).
Concentrate your tiny, tiny amount of remaining technical time on ensuring that your team is not stuck in a dead end or going off the path - and do so via discussion and review of code/documentation. At all costs, avoid doing any "real work" (this can change later).
Every week, discuss with your team * what you were going to do last week vs what actually happened * what you are going to do this week * what risks and issues exist, and what _you_ are going to do about them
Every "reporting period", report to your boss * what your team did or didn't achieve * what the targets this week, month and quarter are (and when they are likely to be done) * what risks ($ x p()) exist (including any current "issues" that may need his/her input) * what issues you want your boss to deal with
This is a pain - and even for a very simple project will take 1/2 day per week. But if you don't do this you are dead.
I've been an engineer for nearly twenty years, with a few years part time work as a tech while at Uni.
Engineering is a profession, and requires education not training. Let me rephrase that: a technical engineer deals with difficult equations. A good technical engineer deals with difficult analogies.
My main gripes with engineering education are two-fold:
- Only engineering design is taught, not engineering discipline.
- Writing skills are neither taught nor tested.
Real-world engineering requires the ability to communicate succinctly and, invariably, a very large amount of documentation.
If you want to develop as an engineer, you will need to understand how engineering, as group of people working together, works. This is where the discipline or practise of engineering comes in. (Sometimes knon as systems engineering) Unfortunately, very few undergraduate courses teach it and even fewer academics believe in it.
There are some notable exceptions (eg. Carnegie Mellon University), but that exception merely proves the rule.
Having moved industries recently I'm stunned to discover that schematics are still done in a drawing tool. I've just burnt 3 days of project time cross checking $#%^#$%^ng drawings, BOMs and netlists because the industry hasn't discovered/developed proper CAD tools.
BTW - I'm dealing with site/city level wiring diagrams, so I don't need to generate drillplot or CNC data. Making Pro/Cable or whatever Mentor's currently flogging overkill. But I do need to do heirachy, automatic netlist & BOM extraction; drawing generation and preferably end-to-end type checking.
Before this law, backups and format & time shifting was illegal. It's just that everyone did it and The Industry didn't care as long as you weren't re-distributing. Mainly because the burden of proof was not worthwhile.
I've yet to read the revised legislation, but the legalisation of these three elements would be a major improvement on the existing situation.
The proposed legislation was actually worse than the old stuff - it added explicit liability etc etc
The same old realities that have existed for at least 40 years in software development, but This Time In New Emperor's (Agile) Clothes. But *Now* with Excessive Capitalisation.
Move along people, there's nothing new to see here.
The unfortunate reality is that these concepts _are_ new to an unfortunately large proportion of "hot young programmers"
I'm currently struggling with an application which has all the hallmarks of being developed by programmers who:
dropped out of Uni because, hey, their skills were more valued in the real world
think an MS certification is more useful than a degree
belief "Knuth" is cussing
have never heard of Steve McConnell, Frederick P. Brooks, Tom Demarco, Edward Yourdon
Or Lisp
I'll not name names to avoid being sued, but every bug I discover indicates:
an ignorance of pre-existing solutions in the problem space;
broken architecture;
the review and test plan was never written, never mind followed.
and that engineering governence is totally missing.
But, dude, relax, all bugs are FITNR. And have been for years.:-(
In short, as an example of Good Code, it's a bucket of shit and it stinks. And no, it still doesn't do what the users want.
Yes, I've been writing programs for over a quarter of a century. So I'm an Old Coot (tm). But I see these whippersnappers making f@#$%@ups that would have gotten me a quick slap 'round the ears. And claiming that they're doing something 3ll33t and, just, like, so, y'know, waay beyond the comprehension of anyone over 23.
The other posters have pointed out that GUI development is a mature art and not much different to other SW problems. It is also incredibly repetitive.
The really difficult part is to make your GUI usable - particularily if your GUI contains any autonomous information (eg. alarms); information from disparate sources/applications and/or your underlying application is complex (eg. a combat system)
At that point you really need to workshop with your stakeholders on use cases;
How many clicks are needed to get to any function?
How well trained/tired/busy/stressed are your human operators?
How many modes of operation are there?
How are you going to manage "status" and "alarm" displays across the suite of screens?
What happens when some application starts struggling/crashing/spewing data?
Training and documentation (user manuals, trainer manuals, debugging manuals) also need to be considered - it's all part of the experience.
At the pointy end of the business, various layouts/schemas are compared by measuring operator hand and eye movement loads!
Ps -
For any reasonably complicated GUI you will want an API between your text/visual _specification_ and your code
Of the energy in the fuel automobiles consume, at least 80 percent is lost, mainly in the engine's heat and exhaust, so that at most only 20 percent is actually used to turn the wheels. Of the resulting force, 95 percent moves the car, while only 5 percent moves the driver, in proportion to their respective weights.
All things considered, only one percent of the energy in our fuel tanks actually provides mobility for the driver - not a gratifying result from American cars that burn their own weight in gasoline every year.
All our problems can be solved by more efficient engines.
Wrong. If you want a more efficient engine, you need to give up your 150 bhp engine and install something with fewer cylinders and something on the order of 80 bph.
Economy cars back in the 80s were far more efficient than today's cars, excepting the hybrids. Back then, the Geo Metro (made by Suzuki) with a 1-L, 3-cylinder engine got over 55 mpg. Cars like that are no longer available, however, because no one wants anything so underpowered.
Ah - I'd have killed for 80bhp from my '78 Escort or X1/9.
But both of those weighed under 900kg. Still big compared to the cars of a decade before.
Gross Weight is the biggest issue, with peak engine output coming a poor second.
Outside the US the vast majority of pre-80s cars were under one ton. And under 2L engine capacity - many under the 1L mark. Petrol rationing and high petrol prices (relative to income) in the Rest of the World ensured that cars were efficient as then practical.
Until we see a serious return to sub-1200Kg "normal" cars (eg. taxis) and sub-800kg "compacts" then actual, real world consumption will have a hope of coming down.*
OBTW - my 1,000kg "compact" also gets 7l/100km - freeway, measured on a 132km daily commute. And it's 0-60mph time is as good as my old, hotrodded X/9.
I've recently changed to a 16km commute - which I usually do on the bicycle. When I do drive, my fuel efficency is down to 12l/100km. And I don;t get home any faster.
But my total consumption is down from a tank per week to a tank per month.
--
* Yes, Virginia, regenerative braking would, as far as thermal loss allows, mitigate mass from the equation. The Prius claims do have this - has anyone dared put their hand on the front disks of a stop-start commuter's Prius yet?.
Plan and test the power down. There are neat two-way locks (the frame is electric, the door keyed) out there. Use them
Avoid Yale-style locks, use Abloy or similar.
Avoid Biometrics and passive RFID
Layer your defences & use multiple factors where necessary (where fingerprints _can_ be useful)
consider what is going to happen when someone quits; loses their hardware or just leaves it at home
But doors are barely the start. Windows, roofs and ceilings need to be considered. While "DIY: Burglar proof your home with concrete" is an old joke, it's a good concept to consider.
For windows 3M has some rather nice film products, which will really slow down intruders Your really secure areas should have no windows, and concrete/brick on all six sides.
But the point of physical defences is merely to delay intruders until the police or security guards arrive. This arrival delay is a key parameter in your design.
Then there's IT, which is another game all together.
Have useful, sensible, published policies, make sure staff understand why they are there and back your policies up with action. Eg.
Audit, audit, audit.
This means having something to audit - ie. records of what is where and who is responsible for it. Who was in what areas (including visitors) and when.
Dock paypackets or downgrade roles for breaches.
Show that the organisation cares - but you need to strike the right balance. In some organisations a breach is is a breach is a breach. In others, "ask forgiveness" is the meme.
Where the letter has been broken, but it was broken in a considered manner taking into account the facts available and aims of the organisation then the resulting management review may form the opinion that it was the right thing to do at the time. (Such as letting the Fire Department into the server room to put out a fire). Policy may even need to changed!
Be consistant and serious.
There's no point having a "no cameras" policy if the VP marketing can wander in with her/his 3G video phone. And if marketing needs to break the rules (such as making glossy brochures)
Be reactive and communicative
If someone identifies a new or changed environment, say "thanks", publish an interim response immediately and add it to your next-period work list. Security is not static.
Now, this is not free (as in beer) so you need to understand how much your management cares (can they spell risk analysis?). Classify your risks, evaluate the cost of breaches and then balance cost vs probability. Have a plan & policy and generate your procedures/work instructions from that.
Seems like a lot of work? Well, look for balance and minimise the amount of material/people you need to protect. "Need to know" and "physical seperation" are good maxims.
If you really care (and if you are subject to SOX or other legislation, your management should) get expert advice from an ex-spook or COMSEC cleared person.
This has been a problem for quite a while. Read "The lost tools of learning". http://www.brccs.org/sayers_tools.html Presented by Miss Dorothy Sayers at Oxford. In 1947.
CastrTroy raises some very good points: my first thought when I read this thread was "key logger".
Which raises the issue of key management: if you haven't already done so, check out the standard methods of key management. (Easy mechanism - hire an ex-spook or ex-comsec person for "advice"). Wikipedia has some links - see http://en.wikipedia.org/wiki/Key_management
If you really want to help, dial in additional factors (RSA's little dongle is an example.)
You really want to do this in the context of risk management: how much you want to spend depends on the probability and cost of any loss.
Just moved jobs, but I was working with a few dudes doing their first formal degree. In their fourties. And another chap who was finishing his patent attorney degree.
The key is that these guys know that this is what they want, and have worked bloody hard to get there.
At your age, get out and live. Get some work in an area that interest you. With Degree Number One lots of doors are now open that weren't. And do it while you don't have a mortgage & mouths to feed.
Me? I'm still trying to find degree No. 2 that makes sense. I'm one of those people who spends as much time as a suit (selling, managing and doing business planning) as I do as an engineer (technical, management or process). It's fun - and useful, particularily as my technical speciality (chip design & verification) is, ah, not big where my family lives.
"Tom Giovanetti,..says a flood of undiscriminated traffic...will bring down...emergency services which depend on VOIP. Is he right or wrong?."
Any idiot who depends on VOIP for emergency services deserves what they get. And failed Communications 101. There's a whole raft of dependible voice services (see POTS) out there.
But, I hear you cry, "they're not 'free'". Funny, that!
... seems to me a lot like trying to teach your hardware guys circuit design without using VHDL, Xilinx, and the other automated tools that make this a heck of a lot easier. "Back in the day, I drew out all my circuits on an easel! If I wanted a multiplexor, I had to understand how the multiplexor worked and write it out directly in NAND gates rather than just picking it from a box of commonly used components!
As a VHDL consulting engineer, the first test we give grads is: "Draw me a flip-flop". "Now turn that into a four bit divider". Stunning how many didn't understand that. How the poor bunnies were expected to do clock recovery or clock domain transfers escapes me.
As a VHDL consulting engineer I spend a lot of time doing stuff like a) making that multiplexer work when time foldered into a pre-calculating CRC engine across a four clock deep pipeline and b) knowing what parts need review, verification or testing.
The differences between training (see MS certified monkey) vs education are:
knowing first principles
exposure to state of the art
being able to extend your knowledge
If you've planned your work properly, 90 percent is rote and should be automated or outsourced to Elbonia at would-you-like-frys-with-that salarys.
It's the other ten percent where the engineer earns half his or her keep. Getting the planning right is the other job.
Computer programmers should be aware of IDEs: one needs to understand the principles behind them and they are the state-of-the-art in one area.
But training on a particular IDE is, well, training.
One word, Kimmie, plesioisochronous
on
TCP/IP Speakers
·
· Score: 1
Audio over TCP/IP. YABunch of losers. Haven't you heard of ISDN or ATM? Fixed bandwidth, fixed latency over IP makes as much sense as mail order video hire
There's another book which is worth the cover price just for three diagrams on the time dependence on the accuracty of estimates; the probability of completion at any particular date and the minumum cost of completing by any given date. Of course it's name escapes me (otherwise it'd be on my shelf).
All coders should have read
Code Complete
A discipline for software engineering (CMU)
Beyond these (and the obvious things listed in other comments) there are a few things a tech PHB needs to do
Solve your team's non-technical and external problems. Keep them feed, watered and tooled up.
track your issues, bugs, externalities and risks.
seperate the knowable (the code grinds) from the unknowable (bug hunts) and handle them appropriately.
Bug hunts need to be contained: if someone cannot fix it in the allotted time, escalate the problem. Even to the point of clean rooming the design.
work out which of your team a) do know how a give task will take them and b) will do their best to deliver on their commitments to the team. And start remedial action on those who don't. "Special" is as in "special school".
review your team's code and designs.
unless you have a real end-of-the-world dead line, kick everyone out of the office at 6pm.
Remember, you are asking your boss/customer to trust you with their money. And your team with their (working) lives.
CD
Planning is the process of bringing the future into the present so that you can do something about it.
Most of the low-level embedded SW designers I know are HW engineers. Sorry. Most really cool low level stuff is _in_ the chips. VLIW anyone?
Now RTOS and CSP in embedded SW requires real CS skills (like knowing your algos and about deadlock prevention etc etc). As does writing VLIW compilers!
In any case the only thing that matters is access to the field and experience You have to get into somewhere that is doing sub-apps work. And embedded processors are everywhere. Try some (or all) of the following.
Universities: Find one with a dept that that is doing ES projects and re-enroll. (Post-grads are considered almost human;-)
get an internship or job with the right division of a consumer device mf'tr. From Ericsson to Palm to Sega to the microwave makers. Then volunteer your way into testing (dev. or mftr) or support for embedded s/w. It's an extremely good laerning experience and no-one wants to do it!
Hack. Build stuff! Get one of the miriad of programmable devices out there (see the ratshack cattledog). Write some serial port drivers for your Palm or PC. Reprogram the EFI in your car with your Palm!
BTW. I've played with secure hardware (eg. ATM and POS terminals). They can and do verify, with serious crypto, what software runs on them. The hardware is designed to be pretty impregnable to even the most serious hacker (Ie. those with submicron etching gear).
A real life experiment: Set up windows-clone themes for you desktop and window managers. Put your favorite office program, email client, MP3 player, and web browser on the
desktop as icons.
Cool - so how do I, the time-challenged techie, do this? Whose distribution do I use?
Slashdot Mirror
Now, where's the "some of my best friends are Mac users" snark?
Seriously, the only unhappy Mac user I've ever met was one who was given a new OSX machine to replace a pre-arc Win3.1 box. With no training.
This is the issue - no training. Everything your mother knows about computers is now worthless - you've just devalued her. Naturally, she's pissed.
As the family IT dude I can only re-iterate that I've never met an unhappy Mac user. Sometimes the transition from Win32 is a little painful (my MIL is doing that now) but once it's done I get basically zero "can you have a look" calls from the Mac users. It just works.
Someone once described management as "the art of making and prioritising lists". I'd also add _communicating_ the lists.
. gov/19960002194_1996102194.pdf). If you cannot state what it is that you and your team need to do to both be finished and prove that you are finished you are lost.
The other half of the job is sheilding your management from your team and vv. While ensuring that no-one is suprised - management, team or customer.
Get reading - both dead tree (dynamics of software development, mythical man month, peopleware, dibert) and online (eg. rands in repose).
Start learning "systems engineering" - the NASA systems engineering handbook is available free on line (http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa
Systems engineering is sometimes described as "engineering management defined so that MBAs don't do it". For good reason.
Start learning about risk management (AS/NZS 4360:1999) and Earned Value Management Systems. And basic accounting principles (esp. cash flow and ROI).
Concentrate your tiny, tiny amount of remaining technical time on ensuring that your team is not stuck in a dead end or going off the path - and do so via discussion and review of code/documentation. At all costs, avoid doing any "real work" (this can change later).
Every week, discuss with your team
* what you were going to do last week vs what actually happened
* what you are going to do this week
* what risks and issues exist, and what _you_ are going to do about them
Every "reporting period", report to your boss
* what your team did or didn't achieve
* what the targets this week, month and quarter are (and when they are likely to be done)
* what risks ($ x p()) exist (including any current "issues" that may need his/her input)
* what issues you want your boss to deal with
This is a pain - and even for a very simple project will take 1/2 day per week. But if you don't do this you are dead.
Engineering is a profession, and requires education not training. Let me rephrase that: a technical engineer deals with difficult equations. A good technical engineer deals with difficult analogies.
My main gripes with engineering education are two-fold:
- Only engineering design is taught, not engineering discipline.
- Writing skills are neither taught nor tested.
Real-world engineering requires the ability to communicate succinctly and, invariably, a very large amount of documentation.
If you want to develop as an engineer, you will need to understand how engineering, as group of people working together, works. This is where the discipline or practise of engineering comes in. (Sometimes knon as systems engineering) Unfortunately, very few undergraduate courses teach it and even fewer academics believe in it.
There are some notable exceptions (eg. Carnegie Mellon University), but that exception merely proves the rule.
Having moved industries recently I'm stunned to discover that schematics are still done in a drawing tool. I've just burnt 3 days of project time cross checking $#%^#$%^ng drawings, BOMs and netlists because the industry hasn't discovered/developed proper CAD tools.
BTW - I'm dealing with site/city level wiring diagrams, so I don't need to generate drillplot or CNC data. Making Pro/Cable or whatever Mentor's currently flogging overkill. But I do need to do heirachy, automatic netlist & BOM extraction; drawing generation and preferably end-to-end type checking.
All suggestions welcomed!
Frankly, instant (back) onis easy - I've designed a large number devices that do this.
It's just that Windoze was never designed to do this - it's not an important feature.
I've yet to read the revised legislation, but the legalisation of these three elements would be a major improvement on the existing situation.
The proposed legislation was actually worse than the old stuff - it added explicit liability etc etc
Move along people, there's nothing new to see here.
The unfortunate reality is that these concepts _are_ new to an unfortunately large proportion of "hot young programmers"
I'm currently struggling with an application which has all the hallmarks of being developed by programmers who:
I'll not name names to avoid being sued, but every bug I discover indicates:
- an ignorance of pre-existing solutions in the problem space;
- broken architecture;
- the review and test plan was never written, never mind followed.
- and that engineering governence is totally missing.
- But, dude, relax, all bugs are FITNR. And have been for years.
:-(
In short, as an example of Good Code, it's a bucket of shit and it stinks. And no, it still doesn't do what the users want.Yes, I've been writing programs for over a quarter of a century. So I'm an Old Coot (tm). But I see these whippersnappers making f@#$%@ups that would have gotten me a quick slap 'round the ears. And claiming that they're doing something 3ll33t and, just, like, so, y'know, waay beyond the comprehension of anyone over 23.
Dude.
It's Crap, Ray, Crap
The questions are:
can they do it well enough?
do they know what well enough is?
do they know what it is?
do they know when it has to be done?
do they know why it (their work) is important?
These are the things that matter
Your staff will probably do it differently too!
The really difficult part is to make your GUI usable - particularily if your GUI contains any autonomous information (eg. alarms); information from disparate sources/applications and/or your underlying application is complex (eg. a combat system)
At that point you really need to workshop with your stakeholders on use cases;
How many clicks are needed to get to any function?
How well trained/tired/busy/stressed are your human operators?
How many modes of operation are there?
How are you going to manage "status" and "alarm" displays across the suite of screens?
What happens when some application starts struggling/crashing/spewing data?
Training and documentation (user manuals, trainer manuals, debugging manuals) also need to be considered - it's all part of the experience.
At the pointy end of the business, various layouts/schemas are compared by measuring operator hand and eye movement loads!
Ps - For any reasonably complicated GUI you will want an API between your text/visual _specification_ and your code
But both of those weighed under 900kg. Still big compared to the cars of a decade before. Gross Weight is the biggest issue, with peak engine output coming a poor second.
Outside the US the vast majority of pre-80s cars were under one ton. And under 2L engine capacity - many under the 1L mark. Petrol rationing and high petrol prices (relative to income) in the Rest of the World ensured that cars were efficient as then practical.
Until we see a serious return to sub-1200Kg "normal" cars (eg. taxis) and sub-800kg "compacts" then actual, real world consumption will have a hope of coming down.*
OBTW - my 1,000kg "compact" also gets 7l/100km - freeway, measured on a 132km daily commute. And it's 0-60mph time is as good as my old, hotrodded X/9.
I've recently changed to a 16km commute - which I usually do on the bicycle. When I do drive, my fuel efficency is down to 12l/100km. And I don;t get home any faster.
But my total consumption is down from a tank per week to a tank per month.
--
* Yes, Virginia, regenerative braking would, as far as thermal loss allows, mitigate mass from the equation. The Prius claims do have this - has anyone dared put their hand on the front disks of a stop-start commuter's Prius yet?.
- Plan and test the power down. There are neat two-way locks (the frame is electric, the door keyed) out there. Use them
- Avoid Yale-style locks, use Abloy or similar.
- Avoid Biometrics and passive RFID
- Layer your defences & use multiple factors where necessary (where fingerprints _can_ be useful)
- consider what is going to happen when someone quits; loses their hardware or just leaves it at home
But doors are barely the start. Windows, roofs and ceilings need to be considered. While "DIY: Burglar proof your home with concrete" is an old joke, it's a good concept to consider.For windows 3M has some rather nice film products, which will really slow down intruders Your really secure areas should have no windows, and concrete/brick on all six sides. But the point of physical defences is merely to delay intruders until the police or security guards arrive. This arrival delay is a key parameter in your design.
Then there's IT, which is another game all together.
Have useful, sensible, published policies, make sure staff understand why they are there and back your policies up with action. Eg.
This means having something to audit - ie. records of what is where and who is responsible for it. Who was in what areas (including visitors) and when.
Show that the organisation cares - but you need to strike the right balance. In some organisations a breach is is a breach is a breach. In others, "ask forgiveness" is the meme.
Where the letter has been broken, but it was broken in a considered manner taking into account the facts available and aims of the organisation then the resulting management review may form the opinion that it was the right thing to do at the time. (Such as letting the Fire Department into the server room to put out a fire). Policy may even need to changed!
There's no point having a "no cameras" policy if the VP marketing can wander in with her/his 3G video phone. And if marketing needs to break the rules (such as making glossy brochures)
If someone identifies a new or changed environment, say "thanks", publish an interim response immediately and add it to your next-period work list. Security is not static.
Now, this is not free (as in beer) so you need to understand how much your management cares (can they spell risk analysis?). Classify your risks, evaluate the cost of breaches and then balance cost vs probability. Have a plan & policy and generate your procedures/work instructions from that.
Seems like a lot of work? Well, look for balance and minimise the amount of material/people you need to protect. "Need to know" and "physical seperation" are good maxims.
If you really care (and if you are subject to SOX or other legislation, your management should) get expert advice from an ex-spook or COMSEC cleared person.
This has been a problem for quite a while. Read "The lost tools of learning".
http://www.brccs.org/sayers_tools.html Presented by Miss Dorothy Sayers at Oxford. In 1947.
CastrTroy raises some very good points: my first thought when I read this thread was "key logger".
Which raises the issue of key management: if you haven't already done so, check out the standard methods of key management. (Easy mechanism - hire an ex-spook or ex-comsec person for "advice"). Wikipedia has some links - see http://en.wikipedia.org/wiki/Key_management
If you really want to help, dial in additional factors (RSA's little dongle is an example.)
You really want to do this in the context of risk management: how much you want to spend depends on the probability and cost of any loss.
The key is that these guys know that this is what they want, and have worked bloody hard to get there.
At your age, get out and live. Get some work in an area that interest you. With Degree Number One lots of doors are now open that weren't. And do it while you don't have a mortgage & mouths to feed.
Me? I'm still trying to find degree No. 2 that makes sense. I'm one of those people who spends as much time as a suit (selling, managing and doing business planning) as I do as an engineer (technical, management or process). It's fun - and useful, particularily as my technical speciality (chip design & verification) is, ah, not big where my family lives.
Any idiot who depends on VOIP for emergency services deserves what they get. And failed Communications 101. There's a whole raft of dependible voice services (see POTS) out there.
But, I hear you cry, "they're not 'free'". Funny, that!
Thog
As a VHDL consulting engineer, the first test we give grads is: "Draw me a flip-flop". "Now turn that into a four bit divider". Stunning how many didn't understand that. How the poor bunnies were expected to do clock recovery or clock domain transfers escapes me.
As a VHDL consulting engineer I spend a lot of time doing stuff like a) making that multiplexer work when time foldered into a pre-calculating CRC engine across a four clock deep pipeline and b) knowing what parts need review, verification or testing.
The differences between training (see MS certified monkey) vs education are:
- knowing first principles
- exposure to state of the art
- being able to extend your knowledge
If you've planned your work properly, 90 percent is rote and should be automated or outsourced to Elbonia at would-you-like-frys-with-that salarys.It's the other ten percent where the engineer earns half his or her keep. Getting the planning right is the other job.
Computer programmers should be aware of IDEs: one needs to understand the principles behind them and they are the state-of-the-art in one area.
But training on a particular IDE is, well, training.
Audio over TCP/IP. YABunch of losers. Haven't you heard of ISDN or ATM? Fixed bandwidth, fixed latency over IP makes as much sense as mail order video hire
There's another book which is worth the cover price just for three diagrams on the time dependence on the accuracty of estimates; the probability of completion at any particular date and the minumum cost of completing by any given date. Of course it's name escapes me (otherwise it'd be on my shelf).
All coders should have read
Beyond these (and the obvious things listed in other comments) there are a few things a tech PHB needs to do
Bug hunts need to be contained: if someone cannot fix it in the allotted time, escalate the problem. Even to the point of clean rooming the design.
Remember, you are asking your boss/customer to trust you with their money. And your team with their (working) lives.
CD
(Anon)
Also being covered in photo.net (which is interested in the photographer's point of view on copyright.)
Interestingly no-one there thinks linking is illegal. YMMV & IANAL!
photo.net discussion
Case law have some info here (pdf)
Yes - one that leads to wailing and gnashing of teeth!
Tearing vinyl and snapping cantilevers - the stuff nightmares are made of.
But if you want some Real Audio and serious hacking try a DIY turntable and motor controler and a real Tone Atm. Of cause all real cartridges require manual hacking.
Now RTOS and CSP in embedded SW requires real CS skills (like knowing your algos and about deadlock prevention etc etc). As does writing VLIW compilers!
In any case the only thing that matters is access to the field and experience You have to get into somewhere that is doing sub-apps work. And embedded processors are everywhere. Try some (or all) of the following.
Universities: Find one with a dept that that is doing ES projects and re-enroll. (Post-grads are considered almost human ;-)
get an internship or job with the right division of a consumer device mf'tr. From Ericsson to Palm to Sega to the microwave makers. Then volunteer your way into testing (dev. or mftr) or support for embedded s/w. It's an extremely good laerning experience and no-one wants to do it!
Hack. Build stuff! Get one of the miriad of programmable devices out there (see the ratshack cattledog). Write some serial port drivers for your Palm or PC. Reprogram the EFI in your car with your Palm!
And then you'll go to jail, have your assets seized and be marked a felon for life.
That's the plan!
BTW. I've played with secure hardware (eg. ATM and POS terminals). They can and do verify, with serious crypto, what software runs on them. The hardware is designed to be pretty impregnable to even the most serious hacker (Ie. those with submicron etching gear).
This product was announced last June/July in "Laptop" magazine. Couldn't buy one then. Can you buy one now?
Cool - so how do I, the time-challenged techie, do this? Whose distribution do I use?
Oh, and my user wants USB support.