Wikipedia defines an embedded system as "a computer system—a combination of a computer processor, computer memory, and input/output peripheral devices—that has a dedicated function within a larger mechanical or electrical system."
Recently while listening to a Soft Skills Engineering podcast Correcting English and Tyranny of the Urgent, a topic was brought up about solving technical debt and escaping the "Tyranny of the Urgent". The discussion that followed was informative, but one of the hosts mentioned a phrase "I intend to ..." that originated from a book called Turn The Ship Around!.
Myself and some friends of mine are developing a course for embedded systems development and analysis. We thought that going with a Raspberry Pi 4 as the target might be a useful thing to do because when the students are done with the course material and labs, they'll end up with an insanely powerful and useful platform to continue experimentation/application with.
In the current world climate we're always looking for the next best screen sharing technology or collaboration tool. Today I came across a need to provide a tour of some code and demonstrate some examples of running various commands. I was on an isolated network so the availability of collaboration tools were very limited.
The following set of questions are merely a sample of the kinds of questions that should be answerable when starting a project. Like an employee and employer interviewing each other to make sure its a good fit, having a set of interview questions for a project is key to knowing the full context of the project and not just the technical opportunities I so often find myself drooling over.
I prefer the analogy of an interview, but the official term for this kind of questioning falls under the study of structured dialog. Allowing people to just coast through a meeting provides little to negative value. Instead of showing up to a meeting with the hope that you can get it to run itself, it can often be more prudent to structure the conversation with some ground rules and guidance. Driving a meeting with deliberate questions and flow can not only be valuable to gain a deeper insight into product development, but it can also contribute to an unconscious negotiation of information that would otherwise never see the light of day.
Author: Menner, Will.
Why are we here?
Why is this transformation needed?
What portfolio will this solution be a part of?
What business or mission model / strategy applies?
What is the larger context within which this transformation makes sense?
What view of the domain makes this transformation meaningful?
Who is the project champion?
What are the top problems?
What are the relevant characteristics of the top problems?
What is causing the problems?
What are the goals and needs of our stakeholders?
What is the post-transformation vision?
What input or data is needed to work the problem?
Who are the suppliers of input or data?
What constraints are we operating under? (e.g. policies, legalities, budget, schedule)
What assumptions are we making?
Who cares?
Who should care?
How do we reach them?
Who are the stakeholders?
Who are the winners? losers?
What potential reactions can we anticipate?
How do we know when the goals have been achieved?
What are the intermediate points where progress can be inspected?
If successful, what is the payoff?
If unsuccessful, what are the risks?
What are the best courses of action?
What are the best ideas for solving the problem?
How should we sequence our actions?
If we were unconstrained, how would we solve the problem?
Has somebody else already solved the problem or a portion of it?
Who are the "performers"?
What makes this project unique?
Who "owns" the solution process?
How is this project different from prior attempts?
What implementation tools and techniques should we use?
If the transformation is successful, what future or unintended consequences might occur?
I originally learned these questions back in April 2020. Since then I've attempted to apply many of them to existing projects. It was surprising how many of them could not be answered by project leads off the cuff. Most commonly, folks would let me know they need to look into that and then never get back to me.
Recently I've become increasingly interested in accelerating my usage of debuggers. For the past 10 or so years I've been a gdb user. By user, I mean I would always use GDB from the command line without TUI, performing breaks, watches, examine, and control commands. More often I have been able to get away from using debuggers by simply getting better at static analysis through tools like objdump. Now with a new arsenal of toolchains and development environments that I've been accumulating throughout 2020, I want to reacquaint myself with runtime debugging.
I am a software engineer that works for the US Government. That comment itself can bring up a lot of mumblings about "government workers", "inherent wasted process", and so forth. While I agree it can feel that way, understanding the difference between "Business Administration" and "Public Administration" has helped me reconcile why the government is the way it is and why you must never think of it as a business. But that isn't what this article is about.
Currently I am working on a project where I am writing a plugin for a service that is a sort of python as a service. You can think of it as a Function As A Service (FaaS) kind of architecture, but the idea is that you provide the service all the python dependencies for your functions when you deploy. Additionally, the service doesn't provide any build toolchains, therefore all dependencies should be delivered as a set of wheels instead of python source distributions.
I've lightly been using git for many years. This was mostly so that I could navigate the linux kernel tree and for exploration of the tool's distributed properties. My current office has been deeply invested in Subversion since 2005 and can't seem to find a smooth transition plan for moving to git.
Due to a growing awareness of unconcience bias, replacing terms that have historically (or directly) been associated with slavery or racially incensitive terminology has become a trend. To be mindful about this entire process I decided to do some "re-google" to learn what Git's context of its famously used "master" branch.