https://www.econtalk.org/christy-ford-chapin-on-the-evolutio...
266 karma · joined February 25, 2015
https://www.econtalk.org/christy-ford-chapin-on-the-evolutio...
Location: Boulder, CO
Remote: Yes
Willing to Relocate: No, but travel to onsite is welcome
Technologies: IoT, IIoT, embedded software (mostly bare-metal), circuit board design for microcontrollers/FPGAs, RF testing background
Resume/CV: www.technesolutionsllc.com
Email: james@technesolutionsllc.com
Techne Solutions is an engineering design and consulting firm that I recently started with a good friend and former co-worker. My background is in embedded hardware/software, PCB design, and test engineering. My business partner is a mechanical engineer focusing on advanced manufacturing (both additive and subtractive). Together, we're helping other small to medium size businesses prototype new hardware and products. There's more info on the "Team" section of our webpage.
Please check out our website(below) and don't hesitate to get in touch if we could be of any help!
Website: www.technesolutionsllc.com E-mail: james@technesolutionsllc.com
Techne Solutions is an engineering design and consulting firm that I recently started with a good friend and former co-worker. My background is in embedded hardware/software, PCB design, and test engineering. My business partner is a mechanical engineer focusing on advanced manufacturing (both additive and subtractive). Together, we're helping other small to medium size businesses prototype new hardware and products. There's more info on the "Team" section of our webpage.
Please check out our website(below) and don't hesitate to get in touch if we could be of any help!
Website: www.technesolutionsllc.com E-mail: james@technesolutionsllc.com
I recently started a small engineering design and consulting firm with my business partner. My background is in hardware(printed circuit board) and software engineering for embedded systems as well as test and systems engineering. My business partner is a mechanical engineer specializing in additive manufacturing and systems analysis.
I've designed boards for SoCs(FPGAs) as well as microcontrollers and develop low-level (no OS) software for the hardware I've designed.
We're only a couple of months old and we're building our network of customers.
Check out our website for more information and please get in touch with us if you have any questions (or feedback!)
http://www.technesolutionsllc.com
E-mail: james@technesolutionsllc.com
https://twitter.com/SteveStuWill/status/1181708302943539200?...
Most of the stages you mentioned above use an external criteria for success and for motivation. If that's the only kind of system you're familiar with, then you probably hadn't had the chance to stop and think "Does doing this make me happy?" because in those systems that question is irrelevant. You do what needs to be done to achieve the grade/rating/performance review and then ask what hoop you need to jump through next.
It seems the people that build truly rewarding careers are generally more internally motivated and because they have a better idea of who they are and what drives and motivates them are in a better position to to say "no" to things.
But this also means that public policy lags public opinion. If you want new (govenrment) solutions, you have to change public opinion first.
Change the public opinion and the politicians will follow but I wouldn't expect them to take the lead.
I do wish his plot lines flowed better. They sometimes make quick jumps as if he was in a hurry or didn't want to take the time to make events more fluid.
Heinlein was definitely weird, but he wrote science fiction. You should sort of expect it to stretch the Overton Window.
The "high-tax, high-spending progressive utopias" remark was mirroring the Paul Krugman op-ed that was mentioned in the introduction to the article.
That department might just be the university side of the accelerator.
The example I know of is the Innovation Deport in Birmingham, AL (my hometown) being attached to the University of Alabama at Birmingham. The university does a lot of medical research and from what I hear, the Innovation Depot is trying to establish itself as the go-to place for professors to take their patents and provide business/engineering/manufacturing expertise.
How does the company treat the employee? I've found that the employee will generally try to mirror how the company treats them. If they feel the company is taking advantage of them, then they might start acting like a Taker just to balance out the relationship.
If they freely give to the company, and the company gives back, then that could start a positive feedback loop.
Sometimes, the company is structured so that the company can't give back, i.e. rigid HR policies about raises/promotions that limit a meritocracy. If the opportunity cost of switching company's is higher, then the employee is probably going to milking the company for everything it's worth to try to even out the relationship.
Asking questions on the manufacturer's forum is useful to because you can typically get an application engineer to respond.
Look through the datasheet and there should be several example application circuits. The datasheet will usually include descriptions about each pin of the module. If you need to use external components to "set" the pins of the module in some way, the datasheet will usually have some equations about how to calculate the correct value and maybe an explanation of where that equation came from. It'll also list maximum, minimum, and typical drive(voltage or current) levels for the pins. When you see the datasheet mention a term you don't know, spend a few minutes looking it up. A few used to describe module pins that jump to mind are "open drain" and "open collector" - those terms tell you a lot about what components you might want to add externally to the pin.
Make sure you understand Ohm's law and the concept of a pull-up or pull-down resistor and when to use them. Also, what a decoupling capacitor does. When you see a capacitor tied to a module pin, can you tell if it's acting like a filter or a charge reservoir.
Keep playing around with it and you'll eventually build up a lot of knowledge and intuition about how to connect everything. And other people have mentioned a lot of great books to use as resources as well.
The only time when people are absolutely required to document something is when it's a deliverable to a customer...so the customer needs to understand the product we're delivering to them.
We're all supposed to be using an engineering notebook to help document designs...but those really only come into play when someone leaves the company and the company is trying to retain as much IP as possible. Though they are incredible useful on an individual level.
Other than that, it really comes to down to finding time to draw a diagram or do a brain dump into a document describing how something works. Maintaining ICDs (Interface Control Documents) describing software/command protocols or hardware interfaces is pretty easy and provides a lot of information.
I found it very valuable. As with any kind of coaching, you could try to work through issues on your own, but it might take you awhile. With a coach, they're there to call you out when you try making excuses and keep you honest. Also, I found that saying and talking about things out loud has a much bigger impact and weight than just thinking them to yourself.
It also helped that this particular EC had worked for about 10 years as a software engineer at my company. When I described work situations and problems, he understand exactly what I was talking because he understood some of the political dynamics of our company and technical language I was using.
We eventually got into building people skills. There were active listening skills, some mental models to help find common ground, and we talked about bad assumptions to make versus good assumptions. For example, it's usually good to assume that your co-workers don't have bad intentions.
Are you trying to find out if it was worth it?
With embedded systems, I can still use my EE background to get my hands on hardware and I'm learning enough software skills to deliver much more professional software whenever I need to.
As a EE, I knew how to code but never got a lot of formal software training so learning git, focusing on my modular code, etc. has been really nice.
For buying a house, I latched onto the idea that I needed a 20% down payment so I wouldn't have to pay for mortgage insurance so I was trying to save like crazy. Meanwhile, the property values were going through the roof and I realized that I'd always be chasing that 20%. I sat down and ran some numbers with a mortgage lender and that made everything a lot clearer. I could have bought a place two or three years earlier and been making money on the property value with essentially the same amount of savings. Probably not true in every area though.
Kind of the same thing with grad school. I needed a break from school after undergrad, so I took a few years. Work experience is great, but I hit a career ceiling in terms of being seen as "qualified" for certain opportunities. I should have just gone back and started taking classes much sooner.
We're doing it by calling a PLATFORM and using an IF statement in the makefile: make PLATFORM=HOST for example. The makefile then replaces the compiler variable, compiler flags, linker, flags, etc.
Another way is to find an author that you really click with and just read everything that he/she has ever written.
About 1 out of every 10 ideas was a good idea, but you had to know how to filter out the bad ones. If you said "no" to one of his bad ideas, he'd say that you weren't listening to his input and complain to your manager.
He was abrasive, condescending, and dominated every meeting. If you said anything to management, their response was "Oh that's just Bob, what a crazy, quirky, eccentric guy!" What they refused to realize was that being Bob's peer was very different than working for Bob. What management perceived as a quirk, was a character flaw that made life hell for anyone working underneath Bob.
And to echo other comments, nothing was done about Bob because management didn't want to take responsibility for the culture of the company. Why risk negatively impacting profits by actually managing your employee when you could blame it on millennials being whiny and you believe that engineers are interchangeable?
He may do both.