fair point though as an EE myself, i don't remember when was the last time i had to read datasheets containing handwritten data. and if so, were not 300+ pages. your team must be working on something very different from what majority is used to

 

fair point though as an EE myself, i don't remember when was the last time i had to read datasheets containing handwritten data. and if so, were not 300+ pages. your team must be working on something very different from what majority is used to

Oh, sorry for the confusion, this was at a ship designing firm, so not really EE related.

 

Evidently my career was rather different. In a small organization with at most 4 engineers, or usually only three, we would spend at most just a few hours developing the concept of a machine, and then at the most deciding the details. Then a few weeks creating the exact design, and another few weeks documenting the details (Creating all of the design documentation so that others could build it. And then a day writing the machine manual that described calibration and the functions, and how to make it work. We did have a writer to create the detailed bill of materials.
The real beauty of a smaller company ia many fewer layers of everything.

 

Absolutely - it’s really common! Most engineers I know (myself included) spend a lot of time manually searching through specs and drawings, and yes, it gets pretty annoying. Outside of Bluebeam or basic Ctrl+F, there aren’t many magical tools; some people hack together scripts, but most just deal with the hassle. You’re definitely not alone!

 

The real beauty of a smaller company ia many fewer layers of everything.

Agreed, till you're dealing with an outside 'design' agency for the 'look & feel' and an external testing house ... things get complicated very quickly!

 

Agreed, till you're dealing with an outside 'design' agency for the 'look & feel' and an external testing house ... things get complicated very quickly!

I did have one project that was a circuit board assembled that was created and built several copies by an outside design house. "ALL" that I had to do was design the package and the external wiring, which consumed about 100 amps from three 7.5 amp hour 12volt batteries, to power a pair of film cameras and three 20 amp floodlights for about two minutes. 100amps regulated from 36 volts no load down to 24 volts thru three NPN power transistors. With a heat sink adequate to avoid burning up within 5 minutes. And the output voltage not dropping below 24 volts.

My opinion on having an outsider do a design is that it can lead to a disaster. That one certainly did.

 

The work flow for myself is inefficient at present, the data structure is a filesystem called EE_library.
The files are (Spice, Discription, images, datasheets) they are matched or paired.
Example: 2n3904 amplifier 10X has a screenshot a discription and data sheet.
The goal is to have a robust sql search that feels like google brings up the circuit image
and prints the discription so I can find what I am looking for.

 

I agree with most of my colleagues here, in that most of us already have some form of such a facility already; it would be impossible to function efficiently otherwise. Previously, working as a design authority in a major systems integrator, I've been in a situation where the end client subcontracted different parts of the system, down to PCB level, to different suppliers, allegedly so that no one supplier had visibility of the whole (other than yours truly!) but I had the problem of dealing with massive disparities between different suppliers take on document management and level of detail in their deliverables.

Now, working as an independent advising a few aspiring start-ups on their product design and documentation processes, as well as doing some of the design work, the basis of the documentation system is a GIT repo containing versioned copies of everything, even down to the datasheet for the lowliest resistor, as well as OCR'd text from images, often translated from Chinese/Japanese, recorded Teams meetings and transcribed audio so thoughts and decisions are captured and documented. And everything can be readily searched with common tools. What I want to try, when time permits (which maybe never at the moment!), is to use AI to trawl this repo to see if we can link, e.g. a high-level design decision with its consequences, e.g. specific choice of a component or a topology.

I could see this as being something that current AI tools might be quite good at. I doubt they would be perfect and would both miss things and claim things connections that aren't correct, but I've been quite impressed with Copilot (the only one I use due to ease of accessing it without having to register/pay) and it's ability to dig out information that is at least in the ballpark, giving me a good place to start my own exploration.

 

My first few engineering jobs did not have any engineering computers, period! so no time was wasted in useless database searches. And there was no need to. When most of it is in your head things can go faster. AND we were a team that cooperated and got along very well. In addition, we knew what we were doing, so not much time spent figuring some stuff out, because we all knew. ( I admit that those were "Glory Days" that would be a real challenge to duplicate again.) How many have jobs where they look forward to most days happily???
My post #23 describes it fairly well. My guess is that it was a rare situation for a group to work that well. The bad, sad, news is that nothing that good lasts forever.
Now, 35 years later, I am mostly a team of one.

 

How many have jobs where they look forward to most days happily???

I have been extremely fortunate in my career in that every professional job I have has been one that I looked forward to the vast majority of days and very seldom found myself looking forward to the end of the day -- the opposite was true and I routinely spend hours working on stuff, even when I was on salary and not getting paid for it.

I've even been very fortunate in the non-professional jobs I've had (like restaurant work) and have only had two (one restaurant and one telemarketing) that I didn't like.

 

The hardest part of any project is not the answer, it's the question.

Exactly. How do you make it do what the customer wants it to do when even the customer isn't sure?

 

Exactly. How do you make it do what the customer wants it to do when even the customer isn't sure?

Sometimes the hardest part is convincing the customer that what they want it to do isn't what they need it to do.

 

Exactly. How do you make it do what the customer wants it to do when even the customer isn't sure?

You talk them away from telling you what to do, and move them over to telling you what they want to achieve.

This takes time, experience, and discipline. Jumping in too early with "That's wrong. Do this" is a great way to alienate people. For thousands of examples of this, browse around this and many other forums. One guy was so bad at crapping all over newbs (as in "You're too stupid to understand my answer; come back in 20 years" (actual quote)) he was banned from this forum for a few years.

ak

 

You talk them away from telling you what to do, and move them over to telling you what they want to achieve. This takes time and discipline.

ak

Something that we spend a huge amount of time doing on these forums.

Don't describe how you are trying to solve your problem, describe for me what problem you are trying to solve.

 

Don't describe how you are trying to solve your problem, describe for me what problem you are trying to solve.

...and, to some extent, why? Sometimes the problem they are trying to solve isn't the problem they are trying to solve!

 

Probably I never had to do any cross-referencing specs and drawings. We never produced a "standard product line". Every thing we did was custom designed and built. The one HUGE PRODUCTION RUN was an order for SIX engine test stands for the same model engine.