Wescott Design Services is going into remission, while I pursue a day job. Job title is Software Designer 5 at Planar Systems -- so any circuit design or control systems jones will have to be satisfied by hobby work or on the side.
In the near term I'll be finishing up current work with current customers; in the longer term I'll probably concentrate on the educational videos and maybe hobby stuff.
Lots of embedded Linux work in my near future, and possibly TDD proselytizing.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
I'm looking for work -- see my website!
Congratulations! (and good luck making the adjustment; the idea of having to BE somewhere early in the morning is anathema to me!).
The folks who make displays? (or, a different "Planar")
It will be interesting to hear your observations of how things (i.e., design) differ when seeing the corporate world *fresh*. (even if you don't publicly share them, I suspect you will "notice" them, at some level)
I think most of us only see it *once*, "fresh" -- and, at that time, have little other experience with which to contrast it.
Them guys. Cool stuff. Not a spinning motor or a low-level signal in sight, but lots of big pretty video displays.
I suspect I'll be distracted by getting into the 9-5 routine for the long term -- but yes, it'll be interested.
Planar seems like a very happy company, and they've made a point to work with me on the whole customer transition thing (basically if I don't mess up with them, they're letting me support my existing projects). So I'm looking forward to it.
I'm replacing a coworker of mine from over 15 years ago (I heard of the position opening up because I was invited to her retirement party), and one of my other coworkers works there, so in a sense it's family already.
In hindsight, it was "educational" when I look back on transitioning
*out* of the 9-5 routine. Just the idea that *I* could control my schedule, what I worked on, the order that I tackled aspects of the project, etc. No need to justify an equipment purchase or worry about exceeding that budget. And, no time wasted in unproductive meetings!
Of course, it was ALSO enlightening to discover there was noone stocking the "stationery cabinet". And, no one ordering the parts for the prototypes -- or, chasing down shipping errors. And, any mistakes were *all* accountable to *me*! :-/
Cool! As a 9-5, I often had employment agreements that wanted to poke fingers in what I did outside of work. In one case, a prospective employer grumbled that he "thought HE would satisfy my need to engage in intellectual pursuits -- what MORE would you want?" (this being the red flag that had me walk away from their offer)
This persisted into contract work -- where clients would want to "own" everything I did for them ("Sure! But, that means you can't benefit from anything that I did for the PREVIOUS client; I'll have to bill you to reinvent all that stuff...")
[If you're "just looking for a paycheck", you view things differently than if you're looking for interesting challenges to consume the hours of your life]
Even better -- as you'll have the inside dope on the place instead of stumbling into it (at some personal expense).
Be prepared to meet some people that believe X works /because/ all the unit tests for X are passed and the console shows a green light.
Usually they have never been introduced to the concept that "you can't test quality into a product". Unit tests developed as part of TDD are highly beneficial, but are not sufficient.
Good luck. I don't have any job and got a traffic ticket for $238 plus $54 to attend traffic school. I plan to fight the case since the signs are not properly posted. If I lose, I will ask for community service and tell the court I have no money and would like to pick up trash on the roads. The city pays $10 an hour for picking up trash. Or, I might get an easier job working in a senior centor. Time will tell. I made an illegal left turn where the signs are hard to see. There is a picture here::
I think I basically had the job when I mentioned at her retirement party that I was seriously looking. Once they realized that I was _really_ seriously looking _at Planar_, the two former coworkers of mine basically dragged me and her manager together and said "hire this man!"
I figured that if it was a nasty place to work there would have been reservations of the "Tim, I'll go put in a word for you if you _really_ want".
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
I'm looking for work -- see my website!
Well, yes. The two main good things about TDD for me is that it makes me think early about how something really should work, and there are finer- grained tests to make sure that if I did something really dumbass it gets caught.
Even with TDD, I still find errors, so I don't live under the delusion that you can test in quality.
Yea verily!!
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
I'm looking for work -- see my website!
If the ticket was a "photo citation" (i.e., if a real human didn't see you and cite you) you can often beat the wrap by hiding from the process server. YMMV. A neighbor did this and the charges were dropped (part of accepting the "ticket" is waiving your right to be served; so, never responding to the "ticket" means you've NOT waived your right to service... making it encumbant on The System to officially serve you.]
Many of the non-profits at which I've volunteered "accept" community service workers. Never having delved into their specific details, it *seems* like hours are exchanged at roughly $10.
Note that you may not be able to avoid the "traffic school" charges; these sorts of things often have lots of little gotchas in the fine print.
[Failing to do the traffic school may also ding your auto insurance premium, disproportionately. Just make sure you understand ALL of the tradeoffs!]
The other dysfunctional aspect of unit tests is that, while they are very useful when making incremental improvements during design, they can be a real impediment in a few months/years time. The problem is that over time people forget which tests demonstrate required properties, and which are merely ensuring behaviour of implementation artifacts. At that point people are afraid to make changes that break tests, even if the tests are unimportant. At that point the codebase has become ossified.
Classic anti-patterns warning of that: unit tests on getters/setters, and/or changing visibility solely to enable unit tests.
Yes to all that. I stopped signing such agreements unmodified some years ago. Now, where the proposed agreement says that they own "any invention... etc" I just add "related to the business of ". Because I invent in many different fields, I need that protection. I haven't had push-back. They want me *because* I'm a polyglot.
It's possible that if, for example, I invent a new kind of office chair while working for them, that they could claim that their employees all use office chairs, so it's related to their business... but I don't think that would last long in court. They don't *sell* chairs.
There was also a remarkably sane ruling some years back in the Australian High Court, where a software guy brought a small library of his own, and enhanced it substantially while working for the company, and after he left they attacked him for continuing to use it. He claimed to have re-written it, and because he had done it "to the best of his ability and knowledge" both times, it was substantially the same thing. The High Court acknowledged that they had hired him because he had those abilities, and the company could not, after he had left, restrain him from practicing his acquired skill and knowledge for someone else, so their case was thrown out.
TDD works where it gives you *another way* to state your expectations. Testing getter/setters never says more about the getter/setter than is said by their declaration, so the tests have zero value.
The important thing is to say "how else can I state this requirement?". If you're using truly succinct code, such as strongly-typed Haskell, there often is simply *no other way* to describe the expected behavior. That's why FP aficionados scoff at TDD zealots. Programming with strong types is always better than using TDD.
Yup, I used a similar reasoning when deciding which RFQ's from my colleagues' firms to ignore/pursue: "I think I'll take a pass on your RFQ, Bob" "Why? It's *perfect* for you!" "Yeah, but I've been paying attention to all your casual complaints about how 'screwed up' the company is and figure it's not likely to treat a contractor any better than an employee!"
Sounds great. When I was looking for work when I got out of college, I had an offer to work at a little company called Motion Message. They did LED message displays, that was in 87. I got another offer and I declined their offer. But I thought it was a neat idea at the time.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.