The other day I ran into a code bug that took a while to figure out. It was so unique (to me) that I thought I’d write about it.
When you design a printed circuit board, you often begin with creating a schematic that will be used as a reference later in the process. Of course, schematics for PCBs can be very long and complicated which can make checking them for errors quite difficult.
Here, we are going to tell you how you can effectively check your PCB schematic. Keep reading to find out more about this.
Imagine yourself in an interview, sitting in front of 5-10 others of your field. Midway through, the group’s questions drift from the personal and work experiential to the assessing and cross-examining. They ask you to step up to The Whiteboard, marker in hand, and prove what you know. Never mind that you’re not fresh out of college and that you haven’t taken a formal test in some time. Gone are the days when a good professional portfolio and list of references, along with a teamwork-minded personality, can get you a job.
These days in the engineering industry, you have to take an impromptu public test to prove your aptitude. I think this interview process is faddish at best and broken at worst.
I had my first whiteboard interview at InVue a few years back. It was ridiculous and a bit demeaning. I failed miserably which hurt my ego for some time afterward. As someone who suffers from impostor syndrome, it wasn’t a good experience. Did they not like me? They must have thought they wasted their money and time on me!
But the longer I work in the world of engineering, and the more confident I become in my capabilities, the more ludicrous I see the whiteboard interview. First, designing on one’s feet, in front of a room of one’s peers, is not how engineering is done. It’s not how it’s ever been done. I’ll go one further: this model of engineering isn’t even good engineering.
Engineering is by definition of process of refinement. A design begins on a proverbial napkin, which moves to paper and screen, and finally to copper etched on fiberglass, or lines of code compiled to chip. These stages are meticulously reviewed by groups of other engineers over months, sometimes years… never in the course of an afternoon in front of a single whiteboard by a single candidate.
Put it another way: if a whiteboard interview ever produced a product in the real world, I’d never ever buy it. It would likely burst into flames and kill its user. Perhaps the notorious Note 7 debacle borrowed just such a design cycle?
And in time, I learned that I wasn’t alone in my disdain for this method of interviewing. There’s a great trend on Twitter where programmers are getting honest about their inadequacies in order to protest this style. I love every single one of them. They each, in their own way, help shatter the unrealistic glass conference room doors that are modern engineering interviews. They reveal themselves to be real designers, not necessarily gifted in quick, improvisational thinking.
So in their spirit, here’s my own tweet, the full story you can read here.
Hi, my name is Rob. I've been #coding professionally in C for 15 years and until 2004 didn't know what a pointer was.
— Rob Lund (@ElectroLund) March 30, 2017
Written in collaboration with Mary D.
I had the most bizarre confrontation last year in my gym locker room — a place that is supposed to be a bastion of privacy, comfort, sometimes camaraderie — from which I haven’t really recovered.
Charles is a jovial sort of guy. He’s in his mid to late 50s. He’s gregarious and extroverted, often seeking out quiet-type guys to chat up. I don’t doubt his sincerity and desire to connect with other men; in fact, it’s a quality of which I’m somewhat jealous, simply because it doesn’t come naturally to me.
This one fateful day, early on in Trump’s ascension up the Republican primary ladder, Charles zeroed in on me. I was his next “project guy” and he was intent on getting to know me. He introduced himself, but I already knew his name from his many other encounters with similarly quiet-type dudes. I’ll be honest: I was dreading this day. The potential intersection of introverts with extroverts can leave the former with anxiety and the latter with anticipation. He had a bull’s-eye on me, while my eyes were firmly in my locker.
But he would not be denied. He invaded my personal space with determination, so I did my best to be cordial. He asked what I did, as most of these conversations start. I returned the question, and that’s when it all went surprisingly south.
Charles, it turns out, is the owner of an engineering company, specializing in cloud-based video streaming. Cool, I thought. This would be a great chance at professional networking, which can be difficult as an introvert. I asked him if his operation is headquartered locally, or if his engineers telecommute. The latter, he says… from Ukraine.
I think my reaction was mostly bewilderment. Fair enough, he outsources his tech labor. A lot of companies do. But it was his almost unapologetic reply that disturbed me. “Americans are just too much work, man!” he implored. He’s a “man” and “bro” type gym extrovert. Every guy is his brother at the gym, where the handshake is substituted with a fraternal knuckles punch.
But I’m an American. And I’m an engineer. I’m an American engineer, and I’m too much work for this employer. I couldn’t feel much more insecure.
He went on to explain that US software engineers basically are too expensive and that the Ukrainians don’t complain as much. A cheaper workforce is basically more grateful.
I countered to Charles that if I worked for him hypothetically, regardless of my talent and reciprocating cordiality, he’d fire me within minutes of showing up to work. Because I’m too expensive.
Charles just looked at me with his bootstrap intensity, a matter-of-fact pursed lip, and said nothing.
I was left with a bit of existential shock, realizing that some corners of the tech world were anything but “safe” for job security. I suppose this can never be the case when there exists regions with extremely cheap labor for sale.
That said, I can only hope that one day the Ukraine experiences its own middle-class resurgence. How does that happen? When it’s local industry exports its goods and not its people.
Until then, Charles and I won’t see eye to eye.
Written in collaboration with Mary D.
Written in collaboration with Mary D.
Artificial Intelligence (AI) has been a hot topic in the tech and innovation world as of late. It has fueled the stuff of great sci-fi movies for generations, but only now is gaining traction in real, marketable products and services.
For the past 3 years, I’ve been working full-time as a software engineer. This has been a substantial, if not calculated, change for me. I’d been an hardware engineer for longer than I care to think about.
Perhaps the biggest, while subtlest difference between the two career paths that I didn’t see coming is this: determinism. I simply love the relative absolute nature of software. I’m sure some might argue me on that one. But, you get my point. For the most, the outputs of any software project can be clearly predicted; the inputs can be nicely quantized, packaged, and displayed in automated fashions.
I love going to work.
Even on the tedious days of making error handling code, it’s still all fun. Exception handling is one of those topics that is grossly underestimated. It’s hard work, it’s time-consuming (and no one appreciates that investment), and it’s rewards are always deferred.
I’m reminded of all of those points when I witness — virtually everywhere in “real life” — examples of horrendous error handling.
Case in point
While attempting to post a mobile deposit to my bank account, I got an error. The transaction didn’t post, for whatever reason. This was on my Android phone, from which I’ve made dozens of successful deposits in the past to the same bank with the same app.
Fair enough, errors happen.
But the error message I was greeted with was the following:
Not much help there, huh?
The point of error handling is twofold:
- Assist the user in resolving the problem
- Provide the developer with the conditions prior to the error from which to find a solution to the problem
From the above screenshot, there’s next to nothing for the bank’s engineering team to go on. The tech support tips I got amounted to, “Have you tried uninstalling?”
It’s no wonder that most people’s relationship with software is terrible. And I’m a software engineer (now)!
I ran across this little humorous easter egg the other day, buried deeply in a software development kit manual:
Simulated Power Fail Test
To begin the test, pull the power plug from the UPS. The first time that you do this, psychologically it won’t be easy, but after you have pulled the plug a few times, you may even come to enjoy it.