Fail Safe. Shit is going to go wrong at the the most in opportune time.
Ensure your production environment will kill your applications at random times. At least you'll be practiced. Uptime is your enemy and gives you a false sense of security. Given enough time, eventually someone will trip over a power cord despite your triply redundant power supplies and backup systems.
I learned this when a memory leak became impossible to track down and so we just killed the process when it reached a certain point. That program was the most reliable thing I've ever seen, eventually every inopportune moment it could have died had been found and the code knew what to do. It would never crash despite always crashing.
I don't really like the 'In relation to your supervisor' part, maybe I'm just frustrated, or maybe in america things are different.
- 'Do not overlook the steadfast truth that your direct supervisor is your “boss.”'
Right, I'm an engineer, a technical person, and as such, I'm the one doing all the hard work. If I'm very good at my job, there will be no reason to promote me or assign me a responsability position, I'm perfect at doing what I do. I'm the only one with the ability to get things done. My boss instead, a non-technical people-person, can roam around and chit-chat all day.
- 'Be as particular as you can in the selection of your supervisor.'
What? How do you select your supervisor? In the real world, you get assigned a supervisor.
- 'Whenever you are asked by your manager to do something, you are expected to do exactly that.'
Exactly. You're a beast of burden, it dosen't matter if his/her requests are utterly absurd or impossible, you are expected to do exactly that. Obey your master.
"Do not overlook the steadfast truth that your direct supervisor is your boss"
Many years ago in one of my first board meetings I remember presenting an org chart of our start-up and joking that I wasn't sure of what the semantics of the lines were. One of our non-execs pointed out, quite seriously, that the relationship is "can fire". After all, employees are there to do what their employer wants in exchange for payment - now in various places and various times what the employee would like to be doing and what the employer would like them to be doing may or may not be closely aligned, but the underlying commercial relationship is still there. Best not to forget it - which is what I think the article was getting at.
'Be as particular as you can in the selection of your supervisor.'
In larger organizations it is often pretty easy to change your direct line manager - e.g. by expressing a desire to be on a project they are managing. Experienced and successful CxO types will also know that it is tricky working out where best to place senior technical people in an organization. I was asked fairly recently by the CEO of the company I work for who I should report to - I thought about it for a bit, gave a sensible choice together with an explanation of why I thought it was sensible and that was what happened. Seemed like a pretty sensible way to run things to me - as it happens the CEO is a engineer (nothing to do with software or computers), which probably explains the no-nonsense approach.
I agree with you on this. I worked on a small team of 3 people and we all reported directly to a product manager. She was great. Not an engineer, but more than capable of knowing what we were talking about. And she's just a nice person and respected us as much as we respect her. But she was a great manager because she would point us at a problem and then get out of the way. She also took our feedback so we really felt like we were part of the process in what we built.
Fast forward to now, our team was absorbed into a much larger group. There's 4 frontend engineers, then they take one of them and make him the "manager". So they're back to 3 engineers. None of us feel like we have any say any more in what we're building.
I finally realized a few weeks ago what my problem with him is, and it's that he should be reporting to me. He's a nice enough guy, and an ok developer, but definitely not a good manager.
I'm taking the lesson in the article and moving to another company soon where I can look people in the eye and feel like they know what they're doing.
Every company I've worked at as a software developer or a manager, my managers have been technical. I got to my position by being capable both technically and managerially. If you don't believe that doing what you are told to do is important, that is the reason that you won't be promoted, not because you are a "beast of burden".
Clearly, our stories are different. I posted my thoughts based on my 3 years experience in a major Fortune 500 IT corp., where 90% of managers are top-school MBA graduates.
My objection to the article was that too often, engineers are considered subordinate by definition, and seen as mere doers with no say in the matter, which is in great contrast with the idea of being an engineer I had back when I was at the university.
Reality is that in some workplaces what you call 'managerial capability' ends up being the ability to carefully choose whom you're going to spend your coffee break or lunch with, false empathy, or just plain arsekissing. Some says this is office politics, but it's a game I don't like to play.
I agree, that's why I don't work in those types of organizations and don't recommend it.
My rule of thumb is this: if technology isn't a major component of what your company "does," you will never be treated with respect by your company as someone in technology.
Interestingly, that was by far the statement I agreed with the most. At my company, all supervisors are engineers. The right supervisor and mentors will basically decide how much you learn on the job, and how far you will go.
This is great content. I really wish someone had told me about the point of focusing really hard on the first (and often trivial) project you're given when I first started. I've only been in the workforce a year, from a business degree at a large bank, but these laws still apply.
This is the first ASME article I havve seen on HN in a while -- so this question is somewhat scoped:
Are there any companies with representatives here on HN which hire or are looking to hire Mechanical Engineers? Bonus for an emphasis in numerical methods and optimization.
I saw one job posting in a "Who is Hiring?" thread several months back but nothing since.
http://memagazine.asme.org/Articles/2010/November/Unwritten_...
http://memagazine.asme.org/Articles/2010/December/Unwritten_...