As someone that was almost entirely self-taught (started as an EE -also heavily self-taught), I’ve looked up many, many noses. One of the manifestations, is that I often don’t know the “official” name of a pattern or the “standard” way to do something, despite being quite good at it.
So I don’t do things the way everyone else does it, and I often fail to deliver or comprehend industry jargon.
But I have been shipping software for my entire adult life. I have an extensive open-source portfolio of extremely well-executed projects that anyone can clone, build and incorporate into a shipping project without worrying about quality or performance. I have had to deliver the goods -in public, and under a microscope- since I’ve started.
I’m highly disciplined, and have been working on large, heterogeneous teams, my entire career. These days, I work alone, or in small teams. Not by choice. Working for a Japanese corporation for 27 years, means that I am very used to hard taskmasters. I’ve had my feelings hurt more often than many.
So I’m used to backing up my rhetoric with deliverables, and watching those deliverables get inspected, criticized, rejected, and improved. It’s made me take Quality rather seriously. It’s also made me quite aware of schedules and deliverables.
Q. C. D.
I’m not particularly competitive, and don’t especially care whether or not I’m “better” than anyone else. I’m used to being the dumbest person in the room (I spent most of my career, working with some of the best engineers and scientists in the industry).
So I work well in teams, know how to bite my tongue, and listen.
Every single day -every single day- I start the day with some scary, insurmountable issue that needs to be solved, or the whole project goes into the bin; and I solve it -often in an unintuitive manner.
So I’m fairly good at solving problems. I’ve been doing it since I was 21, and trained as an electronic RF tech.
I also have dozens of articles, sites, and documentation that I’ve personally written; often going into great detail about how I architect, troubleshoot, test, configure and release. I tend to write in the vernacular, which also means I come across as plebeian.
So I’m pretty much an “open book,” and I’m fairly decent at writing in an approachable, accessible, entertaining manner, as well as coding.
I’d have been happy to have had a more formal introduction to things, but that was not in the cards.
Also, since I’m constantly in “ship mode,” I have to stay focused on practicum, as opposed to theory and exploration. That slows down learning some of the cooler, more esoteric things.
Nevertheless, every day is a new adventure, and I am still learning new stuff, regularly. I feel as if my experience helps me to establish a context that makes learning easier, faster, and more comprehensive.
There’s a lot to learn, and I have miles to go, before I sleep.
> I often fail to deliver or comprehend industry jargon.
In my experience, that alone can act as a powerful blocker. Although I'm quite sure that the jargon thing is being used as a proxy for something more substantial, I doubt that it's a useful one. I suspect it's actually more of a social-group thing (are you “in” or are you “out”) than anything else.
One question about the “Q.C.D.”, though (quantum chromodynamics?). Could it be that you meant q.e.d. — quod erat demonstrandum (≈ “what was to be proven”)? Lowercase to distinguish it from the acronym for quantum electrodynamics.
The Japanese live by it. If you ever want to work with a Japanese company, it's a good idea to know it. I think Deming may have started it.
"Quality":
How do we measure the deliverable? Not just testing targets. Any form of quantification. Progress tracking goes here, as does a lot of things like CI.
"Cost":
What will the cost of the deliverable be? Not just money, but also schedule, the number of folks working on it, prototypes, BoM, progress meetings, buy-in from stakeholders, risk management, etc.
"Deliverable":
What will be delivered? Please describe expected deliverable, what will be delivered at milestones defined in (Q) and (C).
It's a very rigid process (good for hardware), but can be difficult to deal with in software. I've learned to do my own version of it. I've written about it.
BTW: I just demonstrated "jargon," but in a different way. I do not think less of you for not knowing it.
My LI profile is full of testimonials from both. Feel free to ask me for references. I'm not looking for a job, but I can probably scare up a couple of folks willing to go on record on my behalf. I would also be happy to send you some very relevant links.
You could also order the DSLR interface SDK from my former corporation. One of the APIs is a cross-platform imaging device communication layer I wrote in 1995 (in C). I think they still use it.
EDIT: Listen, in all seriousness, I'm a really decent chap, as, I'm sure, are you. I regret that we have begun our relationship on this note, and I will no longer engage you. I scrubbed some of the snark off of this reply.
I wasn’t meaning to be overly snarky in my original comment, it was also an invitation for you to push back with some references of how you do communicate well with others and your code can be easily be maintained by others. This, I imagine, could be due a few different possibilities. It might be that:
1. You do use common idioms and patters, but you don’t know that you do. Perhaps because you haven’t specifically studied them; you might have just absorbed them by cultural osmosis.
2. You might be good enough at explaining things (and naming things) so that you, like Richard Feynman, can explain the most complex things in common simple terms, even though they are not the industry standard terminology.
3. You always find solutions and algorithms which are so simple to understand that you have never needed anything more complex.
4. You have some other explanation which I can’t think of just now.
Instead, what you said was some variation of “my work speaks for itself” and “do your own research”, which does not inspire confidence in your communication abilities.
What I wrote was completely self-expository. It really is who I am, and I'm used to writing that way. It was not a challenge, and it was not an attack on anything (I can easily do "attack" -I'm an old UseNet troll).
As I mentioned above (below?), it saddens me that people see self-exposition from others as weakness and a vector for attack. That's one of the reasons that I'm no longer interested in working for anyone else in this industry, and why I no longer want to be a manager.
Things are nasty these days. Hyper-competitive. We can't just be good at something. We need to be better than someone else.
We can't just be enthusiastic. We need to be combative. Everything is a gladiatorial contest. Thumbs up/down.
After leaving that silo I'd been in for 27 years, I started looking for work, and rapidly discovered what this industry I love has become.
I don't really want to play in the cesspool, but I love to code.
I guess I am "taking my toys and going home," but I am very, very fortunate in being able to do so.
I'm working on a fairly ambitious project, right now, that will (I hope) help out a lot of folks. I have some prior art in the area. I'm working for a non-profit, for free.
This right here. We often talk about "Communication skills". This isn't separable from "being able to describe a problem or solution using standard terminology".
It's no less important to know what common things are called, than it is to know how common things work.
There is no brighter red flag to a than people who just "gets things done" or "solve problems in unorthodox ways", so a candidate who describes themselves as a problem solver that might not know all the "words" for it is to me a big red flag. This isn't gatekeeping or saying everyone needs a CS degree to be a decent developer. Terminology is a trivial addition to the skillset and ignoring it just means one doesn't care about communication.
...and then, there's spending 27 years, working for a conservative Japanese corporation, where they don't know the jargon (but are seriously good engineers). I learned to make things fairly clear, without jargon, and deliver very maintainable code (I'd have been fired, otherwise).
Listen, I understand that researching people before we insult them is passé, but I'm a really good co-worker. I wrote the above in a manner that was all focused on me, not anyone else. I am sad that you saw it as an opportunity to attack.
Maybe we would not get along IRL, and that's fine (but sad). I've spent my entire adult life, working with some of the most difficult folks on Earth (not in the tech industry). I have learned that we all have a story, and we all have value.
If the only way that we can measure our personal worth is to compare it favorably against others, I can't help, there, except to say that it didn't work for me.
So I don’t do things the way everyone else does it, and I often fail to deliver or comprehend industry jargon.
But I have been shipping software for my entire adult life. I have an extensive open-source portfolio of extremely well-executed projects that anyone can clone, build and incorporate into a shipping project without worrying about quality or performance. I have had to deliver the goods -in public, and under a microscope- since I’ve started.
I’m highly disciplined, and have been working on large, heterogeneous teams, my entire career. These days, I work alone, or in small teams. Not by choice. Working for a Japanese corporation for 27 years, means that I am very used to hard taskmasters. I’ve had my feelings hurt more often than many.
So I’m used to backing up my rhetoric with deliverables, and watching those deliverables get inspected, criticized, rejected, and improved. It’s made me take Quality rather seriously. It’s also made me quite aware of schedules and deliverables.
Q. C. D.
I’m not particularly competitive, and don’t especially care whether or not I’m “better” than anyone else. I’m used to being the dumbest person in the room (I spent most of my career, working with some of the best engineers and scientists in the industry).
So I work well in teams, know how to bite my tongue, and listen.
Every single day -every single day- I start the day with some scary, insurmountable issue that needs to be solved, or the whole project goes into the bin; and I solve it -often in an unintuitive manner.
So I’m fairly good at solving problems. I’ve been doing it since I was 21, and trained as an electronic RF tech.
I also have dozens of articles, sites, and documentation that I’ve personally written; often going into great detail about how I architect, troubleshoot, test, configure and release. I tend to write in the vernacular, which also means I come across as plebeian.
So I’m pretty much an “open book,” and I’m fairly decent at writing in an approachable, accessible, entertaining manner, as well as coding.
I’d have been happy to have had a more formal introduction to things, but that was not in the cards.
Also, since I’m constantly in “ship mode,” I have to stay focused on practicum, as opposed to theory and exploration. That slows down learning some of the cooler, more esoteric things.
Nevertheless, every day is a new adventure, and I am still learning new stuff, regularly. I feel as if my experience helps me to establish a context that makes learning easier, faster, and more comprehensive.
There’s a lot to learn, and I have miles to go, before I sleep.