wheelinsupial

I think the video opens up more interesting lines of discussion. There are two points I think the video has that are relevant. One is the discussion on deep knowledge (there is a body of knowledge to learn about software engineering including fundamentals of the discipline). The other is really about the engineering design process (there are domain specific techniques for software that can be used, but it's common to all engineering disciplines).

As other commenters mentioned, the fundamentals are probably more accessible and more known now than at any other time. The minimum bar to enter the field has probably gone down substantially because of all of the abstraction and tooling that exists, and because there is no standards to what job titles are, everyone wants to be called an engineer.

The software PE was removed in the US, but the fundamentals are probably pretty similar in Canada. https://www.egbc.ca/registration/individual-registrants/how-...

Sure, this is probably a little much and there are plenty of people working in the field that don't need to know much of it. That brings us to the vocabulary, which is already in place! Engineer, technologist, technician, skilled trades, and unskilled labor are different categories of jobs within the existing fields of engineering. These range from requiring no formal education to requiring years of formal education. Again, everyone wants to be an engineer and there is nothing in America stopping them from calling themselves one.

Beyond that, I think the survey would need to expand the pool to a representative group working in software. Possibly those who studied CS, those who studied other fields, self-taught without formal higher education, and include people who studied (and possibly are licensed) software engineering, to provide a control group.

Even within the engineering field, not everyone is an engineer or practicing engineering. There are different levels of education and credentialing and those people fill useful positions. For some reason everyone in software insists that they are doing engineering and are an engineer without having studied any engineering topics. (I’m not talking about having to cover the chemistry, physics, differential equations and other topics that aren’t core to software.)

If you search long enough and look for older courses (before all of these online learning platforms like Canvas became popular), you can usually find lots of worked examples. There is no central location to find what you're looking for, but you should be able to find supporting resources.

Is the purpose of the meeting to inform, decide, workshop, or persuade?

If it's to inform, it should be an email, but some people do not read them, so you need to sometimes read the email to them in a meeting.

If it's to decide, do you have the people that will decide called out in the agenda? Do they have the necessary information or have they done the necessary work to make a decision in the meeting?

If it's a workshop, do you have the invitees pared-down to those that will be actively participating? Is there work they need to complete before the meeting, so they can be active participants?

If it's to persuade, these should be in smaller formats. Preferably 1-1 to start, so objections and resistance are raised in low(er) stakes meetings.

Meetings should end with a summary of decisions, next steps, or some other call to action. Preferably these are recorded somewhere and distributed to the rest of the attendees or a wider audience if needed.

I stopped going to EJMR because it was far too much trolling, shit posting, racism, and other bad takes.

As you've pointed out in other engineering disciplines, there are researchers who are pretty deeply immersed in the academic papers and help to move the state of the art forward.

In other cases, there are the societies like ASME, IEEE, ASCE, etc. that put out standards or guidelines. These could either be viewed as documents that you use to plug numbers into formulas or you can try to derive the equations from first principles. Often there are training courses or workshops run by these societies, so that's a place to learn. There are trade publications to learn from as well.

I don't know the shipping industry, so it's possible this isn't feasible.

I didn't realize how large the blog has become. https://scottberkun.com/2012/how-to-make-things-happen/ is where to start to see if you want to read the book. Basically it boils down to: make a list, prioritize the list, execute the list.

There is a lot more to project management than that. For example, how do you present the list? How do you negotiate the list? What happens if you're working on a project with a lot of tech debt and other half finished work that needs to be brought back on track. I don't know if this book talks about that, and I don't really know of any books that goes beyond the very basics or deal with projects that aren't trivial.

Project management is vast. What are you interested in learning more about? Are you interested in agile or waterfall? I'd recommend reading the original "waterfall" paper from Royce from the 70s [1]. I think it's still relevant and helps to dispel "waterfall." For scrum, I'd recommend the HBR article from the 80s [2].

Are you looking for articles on Gantt charts, PERT charts, WBS, critical path. You can look at the PMP book.

Are you looking for stories on projects? I haven't read them, but The Phoenix Project is recommended on HN a bit.

For podcasts, I listen to the Digital Project Manager and PM Happy Hour.

[1] https://www.praxisframework.org/files/royce1970.pdf

[2] https://hbr.org/1986/01/the-new-new-product-development-game

Other than that, there is the standard set of PMP prep resources, but I didn’t find any of those to be anything other than dry and boring.

[1] https://scottberkun.com/blog/

https://oge.mit.edu/graduate-admissions/programs/doctoral-de...

The highest paying jobs I see are at the FAANGS. Other than that, the jobs all seem to be within a few percent of each other. Many employers in my area start off as contracts where you need to exceed expectations for a couple of years to be converted to permanent full time.

I’ve seen employee discounts usually priced at cost plus 5%.

https://en.wikipedia.org/wiki/Legacy_preferences

https://www.forbes.com/sites/deborahljacobs/2013/03/14/why-a...

I don't think anyone in tech writing is trying to put out bad documentation. I've read many complaints about not being given access to the device or software, being left out of license provisioning, being kept out of the loop in sprint planning and other meetings, or being told late in the documentation stage that functionality has changed. If the writers don't have access to blueprints or can't access the software, documentation doesn't get pictures. Some of the devs and engineers respond poorly to requests for screen grabs or doing other administrative work for the tech writers.

I don't think there is a simple solution here. What are the incentives and how does tech writing help or harm. In some cases, helping a tech writer is time spent away from development. Or you can blame UX issues on poor documentation to blame the tech writers.

A facility I worked at started off in low volume, high mix manufacturing (a job shop) and eventually moved into more high volume, medium mix manufacturing. What makes sense for low volume doesn't make sense when you move to high volume.

"Refactoring" happens at different levels. You can look at the entire facility, specific product lines, or specific machines. Generally you care about efficiency and yield. Safety is baked into everything you're doing, so sometimes you need to sacrifice efficiency or yield for greater operator safety.

You can have a product line with initially low sales volume, so you use less efficient or less tooling and automation heavy processes. As your volume increases, you can start to invest in new tooling, machinery, move the production to existing machines, or change the shop floor layout. For example, you can move from hand clamping some pieces for welding, dedicated fixtures / jigs to clamp and hold the parts, up to using robot welding machines for high production volumes.

You can have machines set up for batch processing as independent operations. If it makes sense through having higher volume, you can dedicate a specific set of machines and move them into a production cell.

At a machine level, you can realize that yield is too low and you can look at the design of the tooling or look at the sequencing of operations if it's a CNC machine.

Similar things happen for service operations. It makes sense to have someone manually process or copy and paste some stuff if it's low volume. Once it ramps up, it can make sense to automate in Excel with VBA and then eventually move to a more dedicated program.

Software engineering is a licensed branch of engineering in many places, so I don't think it's that different from other disciplines.

It's available, you might need to search for it and look for the flow charts to see which courses are missing from the other departments.

The challenge is, in many places, you won't be able to practice as an engineer without going through an accredited program.

If you're trying to be a maker or learn more about that, mechanical engineering is probably overkill. There are more accessible books for technologists or technicians that have a much more reduced emphasis on math.

An undergrad degree in engineering isn't sufficient to be an engineer. It's the base knowledge that gets built on during the apprenticeship ("engineer in training" or other name), and you need to learn and use the relevant laws and standards.

If you're able to state your goals a little more clearly, there may be others who can provide better advice or comments.

In general, there is a quote phase before the contract being awarded. In this phase, you're given a blueprint / shop drawing with tolerances, 3D model, and any other specifications that need to be satisfied (e.g., material type, surface finish). If anything is missing, you can submit a request to get the engineering team to update the documents. If you give someone a finished part, it misses so much of the information that's necessary to check the parts. There is a saying, "build to print" because the print contains the key info and is including in the contracts.

It's up to you to determine how to produce the widget. You put forth your quote based on your costs, the material costs you can get, and you factor in your production yield.

The article and the Financial Times article they are citing are light on details. It's not clear if this is an issue with production, inspection, or what exactly is going on.

Usually there are some ramp up issues with launching a new process or production line, so challenges are expected. But 50% rejection is huge. I assume the "casings" being referred to are the back housing / surface of the phone, which is highly cosmetic. If that's the case, the rejection could be for cosmetic issues. It could be related to not hitting the correct tolerances. There are lots of reasons, but the article doesn't really give these details. It's also not clear if every second part is being rejected or if the first half of the batch is rejected or if there are other patterns to the rejections. Could be issues with setup, operation, inspection, or material handling.