Should low level engineers write programs for office use? 13

[radice]

I am curious as to how much a low level engineer is expected to contribute to the company?

The issue at hand: I am a civil engineer with a P.E. and 10 years experience. I work at a small firm and am simply a staff engineer. Should I contribute programming skills to the firm in writing programs that can be used by all the engineering staff?

 

[radice]

Thank you TheTick for providing a succinct response.

Ron and miningman I meant for my question to be very subjective, however, it seems my "attitude" is shining through?

The response from zdas is interesting as it seems to state in his third point that if you can improve on something you shouldn't, because you actually cant write anything useful anyhow.

Also Ron, I'm not sure where the panacea idea seemed to originate. I have written codes before that no one cares about and worked on white papers whose premises go unnoticed. I'm a hard worker and I'm a staff engineer-its ok. I also manage most of my own work so I have a bit of flexbility in what I do with my and am not directed every minute.

I am very happy with the discussion and great points put forth in this discussion, I was eager to seem some opinion.

 

[GregLocock]

Another way of looking at it

Should you as a PE with 10 years experience be doing things that improve your company's processes?

If the answer is yes, does it really make much difference if those things are software, procedures, documentation, lookup tables, training courses, or whatever?





Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[zdas04]

The essence of my third point is that all software requires maintenance and support. If you provide that maintenance and support then your real job will suffer. I have seen that progression too many times for it to be a coincidence. If you try to hand it over to IT to maintain they will either laugh at you or rewrite it to their standards because end-user code is universally not maintainable. I've written a half dozen applications as a consultant and I live in fear that one of those clients will come back and tell me that the code has a bug or they want another feature. That has only happened once and the code was so incomprehensible that I scrapped all of it but the variable assignments and the actual arithmetic and re-wrote the user interfaces. A humbling experience.

I never said that "if you can't improve on something you shouldn't". I could say that, but I didn't. If you have in mind the application that will change the functioning of your company and significantly improve the bottom line, go for it. The IP ownership is really immaterial because even if it is PERFECT for your company it won't travel to other companies. Programs addressing internal administrative procedures are very rarely transportable to other companies because only you have that particular "Cover Sheet on the TPS Report". Everyone else will have a different process.

David Simpson, PE
MuleShoe Engineering

Law is the common force organized to act as an obstacle of injustice Frédéric Bastiat

 

[radice]

Yes GregLocock your point goes back to my question of collective thought. If everyone CAN contribute, great. But CAN everyone contribute to certain processes?

zdas, thanks for the insight.

 

[GregLocock]

That rather depends whether you are trying to wiggle out of doing something. Personally I have avoided assignments involving training, processes, documentation, and so on. That is probably why I am merely a senior engineer, not some sort of manager or supervisor or lead. When asked to investigate some especially tedious problem I have occasionally written definitive rigorous reports on how to solve that problem or calculate the optimum, so far as I can tell nobody reads them or pays any attention. But at least next time it comes up I can do it in five minutes during the first meeting and get back to the fun stuff.

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[ukbridge]

We get graduates to directors in my office to write spreadsheets/MathCAD files in accordance with various codes, which are then verified. Its a pretty common thing in my company at least.

 

[IRstuff]

"But CAN everyone contribute to certain processes?"

Of course, that's supposed to be the essence of management theory for the past 40 yrs; you can layoff all the deadwood. Facetiousness aside, I do not rule out ANYONE who has half a brain. It's often specifically the newbies and outsiders that break us out of our hidebound thinking. This should be familiar to you; you spend days proofreading your penultimate paper, and a summer intern walks by and says, "Is that how you spell ______?"

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[ScottyUK]

Very very true, IRstuff.

 

[moltenmetal]

There's been a tendency here to try to get everyone to use the same spreadsheet so it can be properly debugged and verified. For engineering calculations, I still prefer the tools I've built myself, because I understand them better and am less likely to do something wrong when using them.

radice, if your employer is undeserving of your best efforts, you should find somewhere else to work. Don't begrudge them anything- do them, and yourself, a favour, and get out. You should want to contribute everything within the limits of your skills to your employer to further the interests of their business and as a result, your own interests at least in the form of your continued gainful employment. It sounds like you're stuck in a position where you feel your abilities and experience exceed your job descriptions and pay, and that by writing code for your employer you will be aiding and abetting their continued theft of your talents in this inferior role. If so, you are the reason that employers actually feel there is such a thing as being overqualified for a job.

If they're going to license it for broad distribution and give you nothing in return, that's another matter entirely- but one for negotiation prior to accepting employment, rather than after signing an IP-related agreement as part of an employment contract. It is normal for companies to insist on ownership of all IP developed using hours they paid for.

 

[zdas04]

It is not only normal, but it is proper as well. I invented a downhole pump for gas wells while being paid by a client. They spent nearly a half million dollars for me to develop and test this gadget and to get a patent on the technology. I could have done the work on my own without their money had I had a half million plus enough to live on for the six months I worked on it. Then I would have owned the IP. I didn't. They own it. I've got the patent plaque on my wall, they own the patent. Fair trade.

David Simpson, PE
MuleShoe Engineering

Law is the common force organized to act as an obstacle of injustice Frédéric Bastiat

 

[radice]

very well put IRstuff

moltenmetal thank you for the feedback.

I am a young engineer still and do know I have a long career ahead of me. The question is interesting to me and I have been able to reflect with each of the responses. Perhaps I am somewhat unhappy with the team dynamic and do feel a strong upper level/lower level divide . I have read a paper or two since this post and am thinking I may be more prone to the Collective Learning style in the workplace, but Im not one to really makes waves with the status quo, so thats a lonely road to hoe.

 

[moltenmetal]

Sorry for getting philosophical on you, but I read more into your posts than just the topic.

10 yrs makes you experienced in my book, unless the 10 yrs wasn't engineering- so you may be "young" but you're not THAT young! There's such a thing as having nearly the same 1 month of experience 120 times, but even that teaches you something! Not that you don't learn more every day throughout your career, but what I heard in your posts was an undercurrent of concern really about contributing at a senior level (by writing software to improve everyone's work, yours included) in return for junior/"staff" level compensation and recognition. Correct me if I'm wrong, but that's how it came across to me when reading your posts. I suggest that the solution for that problem is not more humility on your part, as some seem to have suggested, but instead seeking better recognition from an employer whose concept of your ability to contribute matches your own more closely. If, after seeking that opportunity and failing repeatedly to find it, you are forced to stay where you are and eat crow, then you're doing it on an informed basis rather than just sucking up your existing fate as if it were inevitable. Cowering in a job where you feel underappreciated is a recipie for poor self esteem and depression in my book, if you're the kind of person who takes their career seriously and derives much of their self esteem from how they feel about what they do for a living. That describes many engineers and other professionals, but not all- some work only to live, and are able to pack it all away within 30 seconds of getting into the car on the way home.

What others have said here is that you get out of your position what you put into it. In reality you always get less than that- it is inevitable that some of your contributions won't be noticed much less acknowledged or compensated for, but that's part of a job in the real world. I think some people here are finding it a little surprising that it isn't natural for you to just see a need you can fill and jump in there and fill it, assuming it's something the company will actually find useful. Doing that before being asked is one way to get noticed for promotion, if that's your interest.

BTW, dunno if you're a victim of autospell etc., but one doesn't hoe "roads", but "rows", i.e. a using a hoe to weed a row in a garden...hoeing a road would be tough work and with very limited benefit!

 

[rotw]

I've recently developed a small program during spare time. It is a program that was originally intended to help myself n my daily work. I quickly realized the following issues:

- I Have mechanical engineer background not IT, so I could borrow some aspects and tools of programming to reach my objective. However I have quickly realized that as the program gain in size it becomes very difficult to keep track of everything. Especially because of workload reason I had to stop for a while and when I go back programming I was lost in my own subroutines, so a challenge.
To work over the challenge I realized that the program needs to be perfectly structured, in other words - re start from scratch a re write all the modules in structured way - very time consuming and very demanding task.
- I also realized that the program was not optimized. Any solution search algorithm was done by trial an error and more like quick fix. At the end even with a fast machine, the running of the program appeared to me unnecessarily slow. To overcome that the calculations routines needed to be re-evaluated and in fact even involving some sort of mathematical analysis to get to a rigorous approach. That's a huge task too.
- I then realized using the program on daily basis, all the bugs and literally came across errors. It was a blessing that I did not share the program with anyone else. Furthermore it is dangerous to rely upon a tool that is not extensively tested to make quick decisions. For example at the end of the day you come to the conclusion that your accuracy is still not good enough to give valuable insight on your problem and then you still depend and rely on third parties for more representative data. Then you ask yourself is the program really worth it. You realize that experts system are made in house not automatically shared with public even not for money. Sometimes you are trying to compete with software which have been experimentally tested and expertized and developed by hundreds of engineers with huge investment involved.

- Currently, I do not give up because I remind myself that Thomas Edison has broken 1000 of light bulbs before he has succeeded.
So I can see myself starting all over again to improve the program and get from it a real added value to have my work done. Sharing it with my company...I would not do it. If the tool is valuable then If I can, I keep it for me - the other way around, the more the tool is intrinsically valuable the more you - as expert - you do recognize its contribution and refrain to share it with anyone else except if they pay for it - If you tend to share it generously there are good chances that its worth is zero because bottom line it has no impact on a real industry problem as recognized by circle of experts.

I would probably think about commercial exploitation if there is really a niche market for it but then it is really a huge task that I don't see how I can combine with my daily work except taking a long period of leave which is too risky.

I perfectly agree with Zdas in all what he is saying.

 

[IRstuff]

Pogo, who was actually a trifle before my time, famously stated, "We have met the enemy, and they are us!" Going to a new job is not going to solve your problem if you are simply bringing your problem to a new company. Recognition comes with exposure; if you are the best engineer in the world, but there's no one that knows it, is that not like the tree that falls in the forest with no one around?

My Mathcad sheets tend to be pretty messy, and I wouldn't wish them on anyone, but people come by and ask me for them. But, this comes at the tail end of my career, and I'm probably about 10 years away from retiring. I think you need a new paradigm for your relationship with your company. Do you participate in engineering discussions? Are you offered the opportunity to brief others on your work? I'm not suggesting that you toot your horn, but you can matter-of-factly present your work without any boastfulness and put yourself out there. Once your works are known to be solid, people will come to you for programs and what-not without any need for you to volunteer or advertise.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[SomptingGuy]

Some ramblings from a personal perspective.

Whenever I do any serious analysis, I usually end up creating some kind of script file that runs (usually Matlab) functions in a sequence. There will sometimes be the odd low-level program to do things I can't do or can't do fast enough in the high level program. The scripts I create are all throwaway, but there is much overlap and reuse of techniques in them. Each time I do a similar task, I draw on experience and probably evolve my thinking.

I've seen many situations where people attempt to reuse previous code/scripts verbatim. Or worse, commenting out bits they don't want and adding new tweaks for a new situation. Giving away this kind of bastardised (in the true sense of the word) code is very dangerous - the recipient has no idea why things are done how they are done.

In an environment where projects come and go, I think it's best to print out or archive programs and scripts used and then delete them. Do not be tempted to carry them over to the next, similar project. If I've written a function that is really, truly, useful to others, I'll add it to the company "toolbox". I can count the number of these on my fingers in the 20+ years I've been a Matlab hacker.



- Steve

 

[spongebob007]

"Should I contribute programming skills to the firm in writing programs that can be used by all the engineering staff?"

Maybe. Is this programming part of your normal job duties or does it go above and beyond? Are the programs you will be writing in support of a particular job, or are they "nice to have" type things. How much latitude do you have to direct your own work? How much time will this take? How much you are expected to contribute to your organization is set by your manager. Meeting those expectations will probably keep you employed, but if you want to move up, you need to exeed expectations. If writing programs for the department is directly part of your job duties or you are writing something to support a particualr job, the answer is yes, you should contribute because you are expected to. If you simply have a good idea for some program(s) that would be useful to your department, the answer would be it depends. It depends on how much latitude you have to direct your own work and how much time is involved (presumably I am talking about time that would be taken away from assigned work you are expected to do). For instance, I work on a contract basis. My company sees little value in overhead task like training and process improvement because they cut into directly billable hours When working on a contract, I can decide to write a program and charge it to the job as long as I can justify that it is needed in support of this particular job, but I still need to be mindful that it can't take away from meeting the budget and schedule of the job. While great ideas that can improve processes are great, if they take away from time you should be spending on your assigned tasks, no one will care about your great idea, all they will care about is that the work you are supposed to be doing is not getting done. The rule around here is that if you have an overhead task (and process improvement ideas fall under this) that is going to take more than four hours, management approval is required.

So I guess to sum up your question: If you are expected to write programs as part of your job duties, the answer is yes. If this is somthing more along the lines of process improvement and it's going to require more than a few hours of your time, you really need to be having this discussion with your boss and not some random people on the interwebz.

 

[FreddyNurk]

zdas04 said it better, though I'll attempt to put a different slant on it.

The risk pertaining to success in development of software depends on who has the biggest pockets to properly test and develop whatever widget is being considered. If the company has the cash to take the risk on hourly rates to develop something, then effectively they're entitled to the IP that is being developed. If the widget is being developed in your own time on your own equipment, and its not directly related to information or similar that would only come about through your employer, then the IP is likely yours.

Of course, if such a widget was developed entirely independently of one's employer, and it appeared that such a widget would be worth more than the compensation provided as an employee, it'd make sense to quit the employment and sell such IP back to the company. I doubt that this would happen very often.

Also, Open Source aside, there is often a great difference in perception of value of such things, which is also stated very well by zdas04 earlier. My company has a developed PLC codebase for generator scheduling and control that they consider to be very valuable intellectual property. However, its not apparent to them that no one would be interested in it as there are off the shelf devices that do the required function better and cheaper than their custom PLC solution does. Of course, the PLC code breaks every rule on supportability, modularity and maintainability such that every site has its own slight variant of the code, and things break if the wrong one is used. (it should be obvious by now, that I'm not a supporter of the PLC configuration, but I digress).

spongebob007 also raises a great point, if its not going to get a direct ongoing benefit that is larger than the time spent to develop it, then its likely that management won't be keen (not that process improvement is not a good thing, but its not always acceptable to charge it to projects, and its way too easy to spend an inordinate amount of time on an incremental process improvement).

 

[GregLocock]

Incidentally with a PE and 10 years of experience you are rapidly approaching your most productive years, in terms of energy*wisdom*(1-cynicism), so describing yourself as low level is a bit misleading.

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[jgailla]

Star for you, Greg. After 10 years my W seems to have topped out, but my C keeps rising.