At what point are you considered a "Machinist"?

I'd say someone is a machinist if they make a living at it.

I would buy that! Of course being a machinist doesn't mean a person is a "GOOD" machinist!

Every profession is filled with people that work in the profession but aren't good at it or even suited to the profession. In my profession, Software engineering, there are many people that call themselves programmers which would be better described as "spaghetti cooks".
 
Last edited:
I had a friend in high school who would call himself an electrician because he helped his dad wire in a new light fixture in their basement. He would also call himself a plumber because he helped run a water line to a laundry tub. He didn't do this tongue in cheek, he was serious. At the risk of sounding like a snob, it always bothered me that he would take credit for being something that actually takes people years of hard work to really become.

My father-in-law spent 4 years working as an apprentice machinist at Kearney and Trecker, during WWII building the machinery needed to support the war effort. After he worked at Kearney, he spent 35 years working as a maintenance machinist at the Schlitz Brewing Company in Milwaukee. He worked until the brewery workers went on strike and Schlitz decided the cost of brewing beer in Milwaukee was too high and permanently closed their original brewery. The last thing that he did in his working career was to mothball the brewery. The man was a machinist in the truest sense of the word, he could confidently make any part within the scope of the equipment available. On the other end of the scale, I worked at a place that had two Mazak turning centers. The two guys that ran those machines, did very fine work, but couldn't even program their machines, much less move over to the toolroom and make a part from scratch. (They could make modifications to the programs such as changing speeds and feeds). They could also be classified as "machinist" but only because they ran a machine tool.

All that said, I feel that if you are confident that you can make any part within the scope of a well equipped shop (Mill, lathe, surface grinder, drill press) you are a true machinist. If not, you can feel proud to call yourself a hobby machinist or aspiring machinist, amateur machinist, etc.

That is all,
Richard


My nephew swears he’s a machinist, claims CNC if better/faster in all respects, manual is useless and ….. lol, too expensive.

I tried telling him manual will get you the first piece faster, he wouldn’t hear it.

Sent him the inheritance machining video of him making the F1 front spindle in a race against two CNC programmers and I have yet to hear back from him on this.


Spoiler. IH beat them by a small margin.
 
In my profession, Software engineering, there are many people that call themselves programmers which would be better described as "spaghetti cooks".
Eh, doesn't necessarily mean they're bad programmers. I mean, obviously there are congenitally bad programmers out there but these days, with the IDEs and 'tooling' we have, it's an awful lot easier to write basically good code. Easy enough in fact, that most genuinely intelligent people with an interest in learning and the right attitude can do it.

In my nearly 30 years as a programmer, I've created some really quite elegant, maintainable, extensible, thoroughly testable implementations with unit tests at or close to 100% test coverage, that were to all intents and purposes defect free, were scalable and performant and went live, if not on or before deadline, close enough as to make no practical difference.

I've also been responsible for some utter "hell on earth" ones too.:grin:

The difference? The existence (or in the latter case, a lack) of a culture of software craftsmanship.

Interestingly, those workplaces that had a good culture had humble but strong leadership in the technical departments. These leaders would stand up to the those in the company who would try to bully the implementation teams into cutting corners because these idiots (AKA sales people) had a wrong-headed belief that the projects could be delivered more quickly, if we did a poorer job. I'll always fall back to the Uncle Bob quote: "To go fast, you have to go well".

The creation and ongoing support of that good culture (assuming the recruitment policy isn’t to hire people who struggle with tying their shoelaces:grin:) is what makes good software implementations. ;)

Now, high quality software architectural design (especially in real-time, distributed, high-demand systems), that's quite another thing. That requires some special smarts to get the most optimal design.

Which is why I leave that to smarter people than me! :grin:
 
Eh, doesn't necessarily mean they're bad programmers. I mean, obviously there are congenitally bad programmers out there but these days, with the IDEs and 'tooling' we have, it's an awful lot easier to write basically good code. Easy enough in fact, that most genuinely intelligent people with an interest in learning and the right attitude can do it.

In my nearly 30 years as a programmer, I've created some really quite elegant, maintainable, extensible, thoroughly testable implementations with unit tests at or close to 100% test coverage, that were to all intents and purposes defect free, were scalable and performant and went live, if not on or before deadline, close enough as to make no practical difference.

I've also been responsible for some utter "hell on earth" ones too.:grin:

The difference? The existence (or in the latter case, a lack) of a culture of software craftsmanship.

Interestingly, those workplaces that had a good culture had humble but strong leadership in the technical departments. These leaders would stand up to the those in the company who would try to bully the implementation teams into cutting corners because these idiots (AKA sales people) had a wrong-headed belief that the projects could be delivered more quickly, if we did a poorer job. I'll always fall back to the Uncle Bob quote: "To go fast, you have to go well".

The creation and ongoing support of that good culture (assuming the recruitment policy isn’t to hire people who struggle with tying their shoelaces:grin:) is what makes good software implementations. ;)

Now, high quality software architectural design (especially in real-time, distributed, high-demand systems), that's quite another thing. That requires some special smarts to get the most optimal design.

Which is why I leave that to smarter people than me! :grin:

I have worked with some truly talented very intelligent developers during my career and it was a pleasure. The number of developers that are really not suited to the profession definitely out number the talented developers.

For the past 25 years I have worked in the health care industry developing software specific to the industry. One of the biggest challenges is interfacing with other organizations, often government organizations. Government organizations seem to specialize in incompetence!

I could write a multi page treatise on the incompetent practices I have seen... but why? I will say that there are a large number of developers that have no clue about what a properly normalized database structure is and why one is needed. The amount of orphaned and bad data, medical data, is awe inspiring at some organizations.

Just plain bad programming practices are too big and numerous to even begin talking about.

Yes, bad upper level management is the root of bad development practices. I worked for my prior employer for 18 year and truly enjoyed my job and coworkers. Unfortunately we had a very good system and a VERY GOOD team of people throughout the organization... which made us a prime candidate to be purchased by a larger organization, which we were. Then that organization was bought out by an international organization (Sun Life). We had 5 CTO's in 4 years. The CEO kept hiring CTO's with no real experience but full of buzz words. I remember having dinner with one of the CTO's when we were first bought out and asked about his data backbone initiative. His reply was simply "I have 3 masters degrees". When I left the organization they had just hired a new CTO from with in the organization. A VERY SMART lady that had been with Sun Life for decades... on the clinical management side... with ABSOLUTELY NO IT BACKGROUND! Some times I am amazed that big business can function at all! When I left I had 3 email accounts and 4 separate system accounts I had to login to just to start working in the morning, each with a different username. I remember one virtual meeting consisting of a number of people with the Security officer where the Security officer forgot to remove his bong from his desk before the meeting started.
 
Last edited:
Wow...(TLDR) this thread is still going? Are people that insecure about themselves that they need a label/badge to identify themselves? :oops:

Interesting.
 
I have worked with some truly talented very intelligent developers during my career and it was a pleasure. The number of developers that are really not suited to the profession definitely out number the talented developers.

For the past 25 years I have worked in the health care industry developing software specific to the industry. One of the biggest challenges is interfacing with other organizations, often government organizations. Government organizations seem to specialize in incompetence!

I could write a multi page treatise on the incompetent practices I have seen... but why? I will say that there are a large number of developers that have no clue about what a properly normalized database structure is and why one is needed. The amount of orphaned and bad data, medical data, is awe inspiring at some organizations.

Just plain bad programming practices are too big and numerous to even begin talking about.

Yes, bad upper level management is the root of bad development practices. I worked for my prior employer for 18 year and truly enjoyed my job and coworkers. Unfortunately we had a very good system and a VERY GOOD team of people throughout the organization... which made us a prime candidate to be purchased by a larger organization, which we were. Then that organization was bought out by an international organization (Sun Life). We had 5 CTO's in 4 years. The CEO kept hiring CTO's with no real experience but full of buzz words. I remember having dinner with one of the CTO's when we were first bought out and asked about his data backbone initiative. His reply was simply "I have 3 masters degrees". When I left the organization they had just hired a new CTO from with in the organization. A VERY SMART lady that had been with Sun Life for decades... on the clinical management side... with ABSOLUTELY NO IT BACKGROUND! Some times I am amazed that big business can function at all! When I left I had 3 email accounts and 4 separate system accounts I had to login to just to start working in the morning, each with a different username. I remember one virtual meeting consisting of a number of people with the Security officer where the Security officer forgot to remove his bong from his desk before the meeting started.
CTOs shouldn't have any real influence on how systems are implemented really. Actually, other than being the only psychopath in the boardroom (and they're all psychopaths there of course) on the side of the technical staff and fighting their corner when it comes to budgets, I'm not sure what they should have influence over.

The leadership I'm talking about are the departmental level senior managers. Obviously if the CTO insists on poking their nose into implementation details then that's a company to avoid.

Eh, persistence is an implementation detail. If the system is designed properly you could store data in whatever form you like as long as whatever persistence mechanism you use ensures ACID. There'll be CS students just starting their undergrad studies this year who may never know what the various Normal Forms are and will say "Who?" when you mention the names Codd, Date and Darwen and will be all about the NOSQL.

And besides, software engineering talent isn't about knowing a particular persistence mechanism or knowing how to write an efficient search using a b-tree or write an efficent interpreter for your company's DSL.

It's about being able to write code that behaves how it should, that can be tested to exhaustion by automated tests, is loosely coupled and tightly coherent enough such that chunks of it can be thrown away at a moment's notice and that is easily maintainable and extensible.

All of that should be easily achievable using the tooling and frameworks and IDEs we have these days, together with the correct engineering culture.

That it's often not achieved is much more often about companies valuing and incentivising the wrong 'talents' and failing to encourage best practices (none of which should be particularly intellectually challenging for a technical professional).

Google did a large study a few years back and the teams that consistently outrank the other teams in their deployment cadence and lack of defects were not the teams with 'rock star' developers who could knock up an OS kernel in their lunch hour. They were the teams who had good senior management support and a culture of good practice in software design, and particularly, it seemed, those that used test driven development and a fast cadence CI/CD process (I'm still struggling to consistently enforce TDD practice in my own work but I definitely notice the benefits when I do).
 
:grin:Wow...(TLDR) this thread is still going? Are people that insecure about themselves that they need a label/badge to identify themselves? :oops:

Interesting.
I suspect coming on to a thread and offering nothing but a completely uninformed, totally non-constructive, snarky comment is a more telling sign of insecurity.:grin:

Do you walk into bars and join conversations between strangers with an appropros of nothing shout of "BORING!"?:grin:
 
Back
Top