Chris Gammell's Analog Life

Moving up the stack, from hardware to IoT

by

This post talks about my past few years of work doing hardware consulting and realizing just how many clients are looking for help building IoT projects. I’d like to offer more services to that segment of customers, so I need to take on more skills. In the process, I joined a startup that enables people just like me.

Some of the content of this article was also discussed on my podcast The Amp Hour, on episode 569

When we last left off…

The last time I did a career post on my blog, I wrote about how I would be “Redirecting Beams”. That was really an announcement about how I was going to work for Hologram, a cellular MVNO. I was super excited about getting to work on hardware and interacting directly with developers. I was less enthused when Hologram stopped making embedded hardware.

While I still like and use the cellular service that Hologram provides, I politely declined to continue working with them. After stating I was happiest when I was doing hands-on electronics design, my then-girlfriend thought aloud “Hey, maybe you should try to do that all the time. Isn’t that what consultants do?”. I have been doing hardware consulting for industrial and commercial clients ever since via my company, Analog Life LLC. I have also married that wonderful woman, you don’t let that kind of insight go.

What a wonderful and unexpected gift that has been. Moving into hardware consulting felt similar to my experience early in my career: being overwhelmed with all the things I had to learn and then realizing the patterns and pitfalls of design. I was stronger than I remembered. I could do this. I got out of my head and started to enjoy the process. I continued to find work and clients that needed help getting things out into the world.

Down at the hardware level

I love building electronics. I was lucky enough to find clients with interesting problems where I got to design circuit boards on a regular basis. But I realized I needed a large slate of clients to keep me busy, not just one large client. Why?

I normally refer to hardware work as “choppy”. Unlike past jobs at large corporations, small consulting clients don’t need circuit boards built, tested, debugged, and redesigned over and over again. If I’m doing my work correctly, I am not needed after the beginning of the design cycle. Iteration happens after we wring out all of the bugs, including on the firmware and software.

Moving up to firmware

I like making money and billing hours…so why not try to take on more of the work? I decided to start “moving up the stack”, not just designing hardware, but also offering firmware design services to customers. To ensure I was offering a good product, I started hiring tutors, learning more of the firmware side of things, and offering to take on that part of consulting projects for my clients. Not every project was a good fit, if they had very specific or difficult firmware needs. But some of the firmware projects were simple implementations and I was able to use unbilled time and hired help for tough portions of the code in order to deliver at least a proof-of-concept.

If I really wanted to learn how to do all of the firmware work, I should take on the risk of being the end client. An added benefit is I could talk about every aspect of it on The Amp Hour or on the newly launched Contextual Electronics Podcast. This time lined up with the start of the COVID lockdowns, so I took the leap and started the Advanced BLE-CELL (ABC) board for Contextual Electronics.

I started with what I knew: the hardware. I recorded a video per day on a design that had been in my head, based on client requests. It would be a template for various industrial companies wanting to create low-cost, bespoke cellular projects. I would have not only a cellular modem (BG95), but also a low cost and popular Bluetooth SOC onboard (nRF52840).

6 months later, I had a slate of videos for people to watch of me going through the entire process from concept all the way through writing firmware to get the first blinking LED on board. But…what about connecting this thing to the internet?

Building products, not just boards

A quick aside: A couple of years back, a mechanical engineer sent me a DM about wanting to design a Bluetooth-based widget for his shop. He asked if I could teach him how to build one. I explained that I could teach him many aspects of electronics: how an LED worked, which components to choose, how to layout a circuit board that contained a Bluetooth module or SOC. Building an entire product was out of the scope for Contextual Electronics. He politely declined and moved on to build one with a development shop. As I thought about his request and the required skills, I realized I also required this training: it was out of the scope of things I would be capable of doing on my own. I always assumed I would be working on a team that would have a firmware engineer or that I could hire one for a consulting job.

Since I didn’t yet have the capabilities to build the entire system, I hired someone to help me build the ABC system. I wanted to move the project forward, so I decided to hire someone from Upwork. Not only to develop some of the firmware but to teach me in the process (that was part of the job listing).

I also wanted to learn about Real-Time Operating Systems (RTOS), so I included that in the job requirement. An RTOS would enable networking, more precisely controlled operations on microcontrollers, and simplify scheduling of tasks as more was asked of the device. Asking around, I kept hearing about the Zephyr Project, which was a cross-platform, open-source RTOS. I had another client who was also using Zephyr, so after some preliminary research, I chose that for the ABC board.

I hired a firmware engineer named Bilal to write firmware and show me the ropes of Zephyr. He wrote a driver for the cellular modem on the ABC board in Zephyr that we ended up contributing back to the project (pushing upstream). Bilal was a great teacher and we recorded some videos together about the process.

Moving up to the network (IoT) level

Looking at my consulting projects, I realized almost all of them involved adding connectivity to older projects or creating new projects that also have connectivity. What’s more, I had placed myself the same position some of my clients were in. I have a device, I have hired someone to build me hardware and firmware. What do we do with the data being generated from the device? I started looking for options for connecting things to the internet and handling network traffic.

Once again I would need to learn how to to “move up the stack”. It’s not enough to have firmware and hardware designed to communicate from the ABC board. If I wanted to take on more of this project and future IoT projects, I would have to learn how to write software on the receiving side (the internet). Bilal got the project to the point where it was sending MQTT messages (a messaging protocol) over cellular to a test server, but now what?

It was around this time that I got in touch with a friend who lived in the Bay Area. Jonathan had been working at companies like Particle, Google Nest, WeWork, and we chatted about his new startup idea. I mentioned my work with Bilal on Zephyr and he mentioned how his new company was working on a potential solution. I asked Jonathan to come on The Amp Hour in a few months’ time to talk about the startup. He was still in “stealth” mode, so instead, we chatted more generally about what makes IoT difficult. We were not short on topics. I complained about the hardware aspects and the opaqueness of what happens to data after it leaves the device. He mentioned the structural problems of being locked into cloud providers and developing vertically integrated solutions. Embedded devices like the ABC board require such specific architecture to all work together, and many of the choices that impact an IoT platform a year into development are made the day that a hardware engineer starts the schematic for a product. IoT is indeed difficult, and Jonathan laid out a plan for how to make it better. I agreed there’s a lot of room for improvement and went back to work on my shoddy implementation on the ABC board, since I was now trying to make things work on my own.

Switching to an exciting new product

The ABC board was put aside around this time for a very interesting, very new project: my daughter was a few months out from being born. I needed to prepare my consulting clients for me to take some time off. The timing worked out that a couple of my client projects were winding down anyway, so I was able to slide into a self-funded paternity leave alongside my wife.

As I emerged from the early parenting sleep-deprivation haze, I started thinking about the ABC board and restarting development. How was I going to get this board sending data to the internet? Where do I send that data? Who needs the data? How do I manage devices that I have created and deployed into the field? How do I package this up for future clients and sell the ABC board as a “starting point” for their cellular and Bluetooth designs? So many questions to answer.

Jonathan also got in touch and updated me on the progress of the company (Golioth) as he prepared to announce the availability to the world. I learned more about how it basically was designed to answer many of the questions I had. Golioth is built on top of Zephyr. It provides cloud infrastructure to connect to each of your devices. It has a “console” to manage these devices. It talks to MCUboot (an open-source bootloader) on the device to send updates over the air devices in the field. It has a built-in database function called LightDB so you can send and receive updates from the device.

It felt like Golioth was designed for me. It kind of was. Not me. But hardware engineers. Jonathan asked if I wanted to do some consulting around developer relations, helping support engineers understand the value of the platform and how to use it. So I have been doing that since June of 2021, making videos and onboarding new users to the platform. I enjoyed working with the team so much, I decided to join officially as of November 2021, so I can be part of the company long-term.

Moving up the stack, from hardware to the cloud

I have successfully been “moving up the stack” and doing hardware, firmware, and cloud, using Golioth. Towards the beginning of my consulting for Golioth, I also met a small software team looking to build an IoT product, so I recommended trying Golioth for fast prototyping and easy scaling later. I was able to create a proof of concept design using an off-the-shelf cellular modem, some external electronics, and some of the samples that Golioth offers. This prototype could:

  • Communicate over cellular networks
  • Had firmware on the microcontroller that controls/reads
    • Solenoids
    • LEDs
    • Reed switches
  • Had full access to push and pull data to the device from a web terminal (which could also be accessed via a REST API)
  • Had over-the-air firmware update capability

And all of that took 3 hours to build.

I’m not saying I have solved creating any random IoT device. But I am much more capable as a result of this new platform. Now that I’m working with Golioth, I’m going to build my muscles around building fast turn-around prototypes and securely connecting things to the internet. One of my good friends is joining the team and we’re going to work together to build interesting devices.

I still have a lot to learn, especially around Zephyr and the network side of things. But I’m excited to keep building lots of interesting hardware in the future. Check out the Golioth YouTube channel and blog to see what I have been building and talking about lately.

Redirecting Beams

by

For the audio fans out there: I discussed this topic on episode #358 of The Amp Hour

The past couple of years have been a mix of life events for me: I started my course full time, immediately jumped back into the work force (part time), traveled a bunch, started new projects, sold my old stuff, moved to Chicago, I met my podcast co-host in person and started my life over. It’s been a wild ride. Though there have been ups and downs, I’m super grateful for the opportunities I’ve had and the people I’ve been able to work with.

And since I only seem to post on this blog when I have big news these days, I’ll cut right to the chase: I’m starting a new role as a “developer advocate” at Hologram in mid-September.

Hologram is a start-up based here in Chicago, focused on making  cellular data more accessible for internet-connected hardware projects. This takes the form of a SIM card that can be used with a wide range of cellular hardware. The business model is based around enabling projects to connect via cell towers and then charging for data and services. This is currently possible with other carriers, but not in a flexible way and definitely not in a friendly way for developers; this quickly becomes apparent for devs with a large number of devices and not much data needed per-device. The other neat thing is the ubiquitous nature of the SIM card. As an MVNO, Hologram works across a wide range of cell tower operators and in-between mobile carriers, meaning that devices using these SIM cards will work in a large range of the world.

My job will be talking to people building hardware or software and describing the benefits of using Hologram over something else. So…uh…how’d I do?

The past 3.5 years working at Supplyframe have been great. I have really enjoyed writing for the Supplyframe Hardware blog (something I helped create) and running the monthly hardware meetup called Hardware Developers Didactic Galactic (HDDG). One thing I’ve realized about myself is that I really do enjoy communicating information about electronics, even if I’m not the one with the expertise; this should have been apparent from my continued interest in running The Amp Hour (where Dave and I regularly interview people in the industry) and Contextual Electronics (where we have started a forum to get more community involvement and outside opinions).

Working as the “expert” has been increasingly rare as I moved away from daily electronics design. While I think I have become a better interviewer for the podcast, I think my ability to talk about everyday engineering challenges has faded. There is no replacing everyday anecdotes derived from the stress of creating electronic products. I’m looking forward to creating more hardware projects as part of Hologram, even if they are only example projects to help illustrate a point.

This will be the first time I’ll have co-workers and an office to go into in a long time (since 2014). I’m a bit more nervous about this, simply because it feels like I’ll be stepping backwards in terms of “freedom”. But one thing I’ve learned about remote work in the past few years has been the challenges of communication. Even with the near-infinite modes of communication available to us, nothing replaces face-to-face interaction.  I would find myself looking forward to trips out to the corporate headquarters at Supplyframe because of the high-bandwith transfer of information that is possible when you’re sitting around a conference room table. So joining a local company is a cautious step back towards what I think is important in my working life.

That brings up thoughts about other things that are important to me. In fact, many of these things were present at my former job and I want them to be present at any future employer, including Hologram:

  • Motivated, intelligent co-workers — This is an absolute must for me, but I realized over time that co-workers provide a feedback loop that allows me to create better work.
  • Connection with hardware people — Not necessarily just engineers, but I really enjoy connecting people that are excited about hardware. I started a meetup here in Chicago to do just that.
  • Hands on hardware design — This is something I was moving towards at Supplyframe and something that I get to do as part of my course. But I’m excited at the prospect of making hardware solutions for people looking to connect to the internet and solve problems.
  • Work that has impact — At Supplyframe I was communicating with engineers that were solving real world problems. At Hologram, I’m hoping to also work with people that are solving problems using cellular connectivity.
  • Learning opportunities — I am particularly excited about learning more about how cellular networks work “behind the scenes” and best practices for getting devices hooked up to the internet. This in addition to learning more about how to market to a new group of potential customers.

That last point is important and was tied into my decision to move jobs to this new opportunity. I have been trend-watching on The Amp Hour and as an EE over the past few years. There will always be subject matter experts with deep knowledge around a very focused topic (think “analog design”), but this has inherent risks. Companies that require this depth of knowledge continue to disrespect it; they outsource work to job shops or take advantage of the fact that there are fewer options for these kinds of employees. I think for opportunities as an employee or an entrepreneur, it’s necessary to have a hand in all parts of the process. As a result, I want to focus on more and more of the product design cycle, including sourcing/logistics, firmware and software. I recently wrote about the concept of a “solo engineer“; and while I am interested in working in-person with coworkers on a daily basis again, I truly believe the engineer of the future is capable of achieving a full product design using online services and persistence in their product vision. From an electronics standpoint, chip companies continue to consolidate and offer bespoke chip solutions for very targeted application. I think the solo engineer of the future will be tasked with finding and connecting a potential solution as fast as possible. Optimization is less important than proving out the design. This fast design cycle pace is unlikely to slow anytime soon. Not only is this a skill I’d like to work on (fast iteration), I think there are pieces missing in my ability to get a device operational as fast as possible (the software/platform piece). I’m excited to learn alongside all of you.

Again, I want to reinforce just how grateful I am for everyone I’ve met and interacted with over the past few years. It has been a really wonderful journey and I can’t imagine having done it without all the advice and friendship I’ve gained along the way. I hope to return that favor to others in the coming years; if you have a project you want help getting online, let me know!

Pro Bono Engineering

by

Today I’m announcing a new project: Pro bono engineering. I will be offering a couple hours per week to those in need in an attempt to make a positive impact.

The concept of pro bono is nothing new. It is a common practice in law and medicine. Sometimes as a method for writing off hours at a tax break (though that is on shaky ground with the IRS) and sometimes as a public service; the American Bar Association recommends donating time to those in need to maintain good standing with the law community. And while engineering doesn’t really have a centralized organization for licensure (yes, the National Society of Professional Engineers acts as this for some fields), it is still an important thing to think about. Really it’s about helping people who are not able to afford services. Other precedents exist for this as well, like Engineers Without Borders (EWB), but I am not aware of this existing for electronics/tech projects.

I would love to tell you that I’m doing this solely out of the goodness of my heart, but that’s not how idea started. It primarily started because some of my skills are less sharp than they had been in the past. I have been working on a lot of things in the last 3 years, but I’ve been learning mostly outside of the field of engineering: marketing, product management, business administration. All of these things are necessary, especially for running a small business. But the core skills that I talk about and am proud of are my engineering skills. Much like my strife over selling my drums, moving away from engineering is as much an identity crisis as anything else. I am the first person to talk about the power of “learning by doing” (see also Contextual Electronics), so this is my form of that.

That’s not to say I’m not excited by the prospect of social good and helping people move their projects forwards. As you’ll see in the criteria I lay out below, the project goals will also help me decide which project to prioritize. Really instead of “social good”, I’ll try and focus on “impact”. If I can help a software engineer move a project forward for a device that helps a lot of people (even if it’s a commercial project), I’ll favor that.

But enough about the motivations, as this is really an experiment. I’ll only know it is working once I have tried it out! Let’s take a look at some of the restrictions and guidelines for projects I’m looking to work on:

  • This will be no more than 5 hours per week of my time.
  • You will need to pay for parts. Even when a friend mechanic works on a car for “free”, you’re often paying for the parts.
  • I will be working in KiCad. This is my eCAD of choice. If there is mechanical or other work, I’ll help out how I can (have been learning Fusion 360).
  • I will be talking and writing about all projects I help with. If you have a “secret” project, you probably should be hiring someone to help you out.
  • There are restrictions on what I’ll agree to work on, including life-critical and dangerous projects. Really I am the only person who decides what I’ll be working on.
  • Projects with existing documentation (even background info counts) will be given priority as that helps to assess the project. There is a place on the form below to add info about where to find the documentation.

So the last thing is that I am taking the “applications” for this via Google Forms. You can access the form directly here and I will attempt to embed the form below.

I am hopeful I will be able to help a lot of people and find great new people to work with. If you have thoughts or questions, please leave them in the comments below.

Thank you Antonella Beccaria for the picture of helping hands

Internet Denizenry

by

I’m rounding out a stint of travel to Serbia, Germany, the UK and am now back in the states. It has been a wonderful experience, even if I am ready for a bit of quiet at home for a while.

One thing that strikes me as I travel to these foreign destinations and meet new people and experience new things: work stays the same.

This is the effect of spending a large percentage of time in front of a screen. No matter what the surrounding environment, with a wifi connection, a laptop and possibly a VPN, I can access the exact same setup as anywhere else. No surprise to most people, why should work ever change for an internet worker?

It’s actually the effect of having that consistency of experience that intrigues me. Very few other professions (that aren’t primarily screen based) would have the same effect. A doctor in a different country would need to learn the local trends and traditions. A construction worker would need to figure out how the building codes are different. An accountant would need to learn the local tax rules. With the internet, it really starts to normalize.

This combines with the cultural homogenization I observed. I’m not saying that all of the places I visited are converging towards the suburban Ohio experience that I’m accustomed to (thank goodness). But there is a sneaking suspicion that advertisers are following me from country to country as they attempt to penetrate new markets. Life is not a series of advertisements (I hope) but the availability of comforts and fashion across the globe has me questioning daily experience in another country.

On a broader level, this starts to make me question the idea of location and citizenship at all. Hopefully I don’t sound ungrateful for the comforts a US passport and background affords me. But now that I start to experience similar daily experience in and out of work and an overall convergent culture and I start to wonder what differentiates one country over another. On the surface it seems like:

  • Currency
  • Power standards (plugs, voltages)
  • Language (though I benefit from the world moving towards an English standard)
  • Tax structures, bureaucratic struggles and the services the pay for, such as healthcare.

Yes, this is a drastic oversimplification. But calling out these things as some of the large differentiating points, I really wonder what a “internet” passport and citizenship would look like, some kind of new world order simplified across all the willing participants of the web. Not just a tax haven and a lack of regulation (looking at you SeaLand), but an actual society of people that are living and working online. A government run by hackers and makers, optimized for low overhead and allowing maximum flexibility between the various geographies of the world. It would probably be a mess, but allows for an interesting thought experiment. Where would move people choose to live in the real world? How would that further impact culture? What defines citizenship in the first place?

Ultimately, I am grateful for the opportunity to work from a variety of locations and bring my work with me. I continue to be an American and likely would choose that again if given the opportunity. Perhaps I’ll start working from more varied locations though.

 

On The Road Again

by

One large change in my transition from a desk-based engineer to a “product manager helping desk-based engineers” (and part time basement-based engineer) is the sharp increase in travel. I am writing this post from a hotel room, as I likely will others in the future.

Travel has been a blessing. I get to meet more people in person, make deeper connections with those I have met online and see parts of the world that are drastically different than my basement.

However, I am learning that I thrive in situations that are boring.

A large part of my success on projects like Contextual Electronics was a focus on routines; these were natural extensions of excess time while firmly planted in my house in the midwest. There wasn’t all that much to do on any given weeknight and any social activity takes planning because of the relative distance of my friends in the area. When I’m home, I stay on track with my daily habits. Travel throws a wrench in the works though.

One problem relates to my last post about co-workers. I often work by myself, and that’s when I get a lot of work done. But when I’m with co-workers on the road or at the office, I want to spend time with them! Friends…right next to me! This means dinners and social events and simply sitting down and chatting for extended periods. My rather packed habit schedule does not go for this though.

Ultimately, it comes down to balancing fun and social things with work. That’s the nature of work, right? If I want to continue improving myself, my course and my life, I need to sometimes pass up going out for a beer. I think in general, the coincidence of alcohol and social functions also needs to decrease on travel, but that is a topic for another post. The first thing I will be focusing on is striking a healthy balance between spending time face to face with people I don’t see very often (which is important) and getting work done for the future (which is also important).

Thanks to Moyan Brenn for the picture of the road.

On Having Co-workers

by

I thought the thing I wanted more than anything else was to work alone. By myself. With myself. For myself.

Quit my job. Strike out on my own.

Sure, no job actually exists in a vacuum. The basis of commerce is one entity paying another, which sets up a power structure. So I assumed I would be working for my customers. That continues to be a very rewarding part of Contextual Electronics (CE). Hearing about the problems they’re having and working to solve those problems tickles my teaching nerve and my engineering nerve (the one the rewards me when I solve problems).

But I thought I’d be on my own and that’s what I really wanted. I was kind of wrong.

Shortly after leaving my last job to work on CE, I joined Supplyframe part time. We have been doing exciting things like the Hackaday Prize (now in its third year) and building tools I’ve always wanted for myself as an engineer. That has become a bigger part of my life and I really like where the company is right now and where it’s going. Today marks the two year anniversary of that decision. Also along the way, the direction of CE has also taken a turn towards embedded, so I brought on two part time instructors, who also act as advisors for both the content and the site.

Co-workers challenge me.  They keep tabs on me. They inspire new ideas during our discussions. They prevent me from getting lonely, even working remotely in a basement in Cleveland (the “Co” in “Co-workers” meaning working on the same stuff, not necessarily in the same location).

In both of my jobs, I now work with people on a daily basis. Engineers aren’t supposed to like that. I’m supposed to be a lone wolf. I’m either a bad engineer or a true pack animal, because I enjoy having co-workers again.

Thanks to Lex Photographic for the picture of the Lone Wolf

As big as…space

by

Last week on my electronics podcast, The Amp Hour, I did something uncharacteristic: I mentioned where I’m working, while I’m working there. Normally I don’t talk about my place of employment until after I have left, which has always served me well. There is no conflict of interest in talking about work that protected by non-disclosure agreements (NDAs).  This time is different though, because the nature of the company is different (and my role will be more public facing than my normal role as an engineer).

I’ve been working with Supply Frame part time, in addition to my work on Contextual Electronics. It has been great working with a team dedicated to making the supply chain (the complex system of vendors and distributors) a bit easier to navigate. As it so happens, Supply Frame also purchased a popular blog site a while back that I have always been a fan of, Hackaday. That site highlights fun projects from around the web and is a great way to keep up on recent innovations in personal projects.

So why all this explaining and build-up? Well I’ve also been asked to help out on a project as part of Hackaday. In fact, it falls in line with my past experience of running the 555 contest back in 2011.

Hackaday is sending the grand prize winner of a new design contest to space. Whoa.

When they first told me about this idea, I figured they must be joking. How the hell would this be possible? Well, it turns out there are more and more commercial space flight options opening up. These days with enough money (and yeah, it’s a lot of money), you can buy a ticket to ride. So that’s how we’re doing it.

The contest itself is really exciting as well. The goal is for people to build “open, connected hardware”. In my experience (with the 555 contest), you need a constraint to base the contest around; openness as a constraint is particularly interesting. Not only does it encourage people to design something cool (like an open source Nest Thermostat or similar), but it also then allows that hard work to be built upon later. I’m a huge fan of open source hardware and up until this point, the way most people are rewarded for their openness has been a community building up around their project (a prize unto itself); now they can also win a trip to space (or other prizes).

I put in a couple emails to friends and acquaintances and we’re going to have a killer judges panel as well; they’re all as interested in sending open hardware experts to space as we are. Bunnie, Limor, Dave Jones, Elecia, Jack Ganssle, Ian of Dangerous Proto, Joe Grand, Sprite_tm. We’re also announcing the final winner in Germany at the huge tradeshow Electronica.

Anyway, I’m super pumped and I hope you are too. I feel very lucky to be involved with such a fun project and hope lots of people will be interested in submitting an entry.

Don’t Wait For Permission

by

I have corresponded with a international student for a few years now. I honestly can’t even remember how we met online and it doesn’t matter. He showed interest in my work and we started talking and have continued as he has graduated from US university and found a job locally. Recently he asked me:

I don’t like my current job. How can I get a job at Google?

I asked him why he wanted to move to Google. High pay? Exciting work? Big challenges? A recognizable name on a resume? All of these things can be had at other companies, many that are easier to get to than Google. Without having someone on the inside of Google that knows his work, I told him that he will be forced to go through the same process that every other interviewee does when applying to jobs posted online…and that’s a lot of competition. Not that competition is bad, just that there are so many better ways to find interesting, rewarding, high paid work.

So here’s the advice I give him and to all of you and any other recent graduates or young people looking for work:

I recommend you pick an open source project you think that Google would work on (or any other target company you’d like to work with). Maybe it’s a robot. Or a new API. Or a delivery service for soggy cereal milk (really?!?).

Next, start working on that project. If you can’t find an existing project, start your own (I started the BenchBudEE as part of Contextual Electronics because I didn’t see anything else in the marketplace). If you can’t do it alone, find some others that might be interested in the same topic. Find discussion boards or subreddits around the topic to find like minded people (hopefully with complementary skill sets)

Finally, spend all of your waking moments not at your job or school working on this project. You won’t be paid at all and likely never will be for this project. Work really really hard on it. At the end, you’ll either have one of two things

  1. A job offer from Google (or whichever company you were targeting)
  2. A great project and great experience.

If you don’t want to do the hard work when you’re not already working for Google, they likely won’t want to hire you in the first place.

Don’t wait for a company to give you permission to do interesting work. Go out there and find it and do it. The world is a playground!

First Day Rejection

by

Well, it’s my first day out on my own and I have already had a rejection. Whee!

In reality, it was a contract job that I bid on without too much expectation of getting the work. I definitely was not counting on this work as part of my survival in my new jump to self employment. Mostly it was an interesting problem that I would have enjoyed working on and I would have been able to work with some good people; this is my main disappointment with not getting the work.

However, I did get feedback on my proposal, which is great. A lot of times, people will just blow you off and you later get the, “Oh, we went with someone else” a few months down the road. The feedback was positive, that the proposal was well enough done, which was reassuring because I haven’t submitted many in the past. The reality of the situation was that they decided to go with a completely different architecture for the project, which I had no chance of doing well. As such, their decision to not go with me was a good one.

I suppose the biggest disappointment after “not getting the work” was that I failed to convince them to see my solution as the best solution (really the point of any proposal). I knew this would be an uphill battle from the beginning as the project manager seemed to favor the other way of architecting the solution. But how do you change someone’s mind when they have been envisioning a particular type of solution from the beginning? This isn’t isolated to this situation, I have experienced a preconceived notion by managers in the past.

I could complain about a manager making a decision in a vacuum, but the truth is, I don’t know if this decision was made in a vacuum. In fact, it could be that the solution that was asked for is in fact the best way to go forward. If I really wanted (or needed) the work, I suppose I could tailor a solution to the manager’s preconceived notion, quickly iterate on it and show how it ultimately will fail as a final solution and then be ready to propose the alternate (better) solution. Is this realistic as a contractor? No. I think from the outset if you plan on failure, you’re going to hurt your reputation. Plus, as I mentioned above, I have no way of actually creating the (preconceived) solution, so this wouldn’t have even been an option for me. I think the only real way for me to win this (long term) would be to develop this solution on my own for fun/educational purposes and then be at the ready to offer it up later as a possible solution, assuming the preconceived method does ultimately fail. In reality, I have other things to get done, so I’ll just wait and see if they call and I’ll start on the work then.

So yeah, first day out of the gate and I’ve already had a rejection! It feels good to get it out of my system…I’m sure no more will happen in the future…right? RIGHT? Riiiiiiiiiiiight.

Recent Posts