That's probably my own experience and it involves a low sample size, but as a small business owner, Id argue that you can really benefit by dropping the degree barrier and looking for other indicators of maturity and reliability.
That's probably my own experience and it involves a low sample size, but as a small business owner, Id argue that you can really benefit by dropping the degree barrier and looking for other indicators of maturity and reliability.
Added: It really was quite like this Dilbert comic https://dilbert.com/strip/2019-01-21
Later on I did some framing work on my own. Ran into several cases where the designer completely ignored the dimensional instability of wood due to changes in humidity. Often that was really hard for the "no education" guys to fix.
Some contracts (mostly government) have a strict definition of what an FTE is/can be. Because it's the government, instead of having a nuanced understanding of the field, they treat everything as a series of buckets - "you have a college degree? You're Engineer II. No degree? Clearly Engineer I." There's some wiggle room with technical experience and whatnot, but it's tricky to do.
So, when the government customer puts out a request for bids, they'll say something like "we want a system that does X, Y, Z, and we expect this to require 3 FTE 2s and a part time PM for 6 months" - generally establishing the upper limit of what they'll pay/how many hours should be billed to the project. (This gets interesting when you realize that the customer doesn't really know how the sausage is made, so they talk informally with contractors to get a feel for what's possible/go to a team they've worked with before, get a feeler for what the requirements should be for a project/what to expect cost wise, and only then put out the formal request. 9/10 this means that the government PM has a team they want in mind, and basically has the team write their own requirements sheet).
Any way, long story short the credentialed designers look good on a contract, and produce valuable designs that can get approved/validated by the Powers That Be, while the mechanics who implement things come up with the product. Both are providing value, just in different ways.
Also, sometimes you need to start with a lovely design, even if you know it will never survive production.
I've hired dozens of Software Engineers and could only tell you the degrees and/or schools of a couple of them. I don't even look at that. Can you demonstrates proficiency in what I'm asking you to do? Do you seem intelligent and willing & able to learn? Do you fill a gap on the team? Those are the things I want to know.
Software engineering is a trade skill, after all.
A well-intentioned intern can make a programming decision in an afternoon that might take a team of senior SWEs months or more to clean up later once the code or data is being used for something important.
We brush the bad engineering decisions under the rug by calling them "tech debt", but the truth is that if we invested more up front in hiring people with big picture skills and experience we'd probably save significantly more money in the long run, despite their higher salaries.
And a new maintenance tech with the wrong grease gun can cause millions of dollars of downtime. This kind of risk exists in all industries.
You don't need a degree for plumbing. It comes in damn handy when you're doing things like flow dynamics or combustion simulations
Just like aeronautical and construction engineering, surgery, dentistry...
I usually tell people "I program computers" when they ask what I do. I used to say "I do computers" but people are more used to computers and software now so fewer people ask, "so, you do computers?" so I had to change it up a bit.
They tend to just get things done, without spinning themselves in circles building unhelpful mountains of abstractions or searching high and low for a place that they can apply their algorithms coursework.
Though the flipside is that they make lateral transfers very easy, so those that are the most motivated by more challenging or even just more CS-oriented work find themselves drifting towards it.
On the other hand, even after you've performed the "real work" of thinking things through, the fact that your code works isn't the "real product". The real product is the degree to which the code can be understood, maintained, and extended.
I think that the idea that software engineering is a trade skill produces two problems:
It encourages management to discount software engineers' expertise and view the planning that comes before writing code as a waste of time.
I think when people today say "trade skill" they think of things like factory work and relatively routine construction. However, a programmer is more like a traditional artisan who must always be honing their craft and learning new techniques.
In my opinion, a better way of looking at it is that companies should start actually treating software engineers like engineers. I.e. by viewing them as professionals with the expertise to inform project planning and a professional obligation to follow best practices and design.
Much like being a software engineer the real product of a carpenter is how what the build withstands the elements, can be repaired, maintained, and extended, and that is only achieved after putting in the thought and design that comes before construction. Much like a software engineer, a carpenter must keep up to date on building codes and regulations, different materials and how they are used safely, and collecting, maintaining, and extending their tools.
Software engineers often talk about "sharpening the saw". That's literally something a carpenter would do.
It really depends. I don't think you can compare writing a CRUD to writing a hardware controller, for example.
I think HN tends to be in a bit of a web bubble. There's plenty of software engineering that has nothing to do with the web.
But seeing how I taught myself assembly language in the 80s and learned how to optimized programs to run on 65C02 1Mhz computers with 128KB of RAM in middle school, I don’t see why teaching yourself how to do low level hardware programming is any different than learning anything else.
Yes and I spent 12 years doing C bit twiddling.
Most of these programmers have moved on to Java, Javascript, and Python.
Those doing "C bit twiddling" are the other C programmers. Most commonly I hear the phrase from people who are capable of this low-level programming but never liked it. People using the phrase seem to be mostly people who have moved on to languages like C++, C#, and Go. People actually doing the "C bit twiddling" seem to just say "C programming" as you have suspected.
So I guess it is a way of saying "C, including the parts I don't miss" for people who could do it but never liked it.
I've always been very grateful and always been willing to do any work I can or go out of my way when I can to get the job done. This stems from the fact that I am grateful for my boss for "taking a chance on me". I know hiring doesn't always work out and I do what I can to be the shining star of people they look for, in the future to hire.
It was very rewarding when in fact my direct manager said to me in conversation " How do we find more people like you?"
Probably the best compliment I could have received.
Before anyone else chimes in, I am not underpaid. I work for a great company and am probably paid above market average.
Some would call it „willing”, some „more desperate”.
I wouldn’t have called Feynman desperate. http://longnow.org/essays/richard-feynman-connection-machine...
Some things just need doing, like buying pencils.
Being willing to take on tasks as menial as picking up some pencils for the team might be a symptom of desperation. It equally might be a symptom of a lack of egotistical arrogance [that one is above such tasks].
Also called into question is the definition of a lesser task. You see, in the Feynman scenario they could not have got much work done in a short time without more pencils—no matter who was fetching them.