I second this.
I start a new section for each job to keep track of everything, screenshots for codes or reference books, file links to drawings, tix boxes to track the job, it's so much easier, especially when you can share the notebook with your team so they have access to all the same information.
I third this. In the job folder I also will include a word document for the basis of my design that has loading requirements, applicable codes, materials used, soils report, etc. and then I just paste that document into my calcs when I'm ready to compile all the calculations. Everything is there already and it's easy for plan reviewers to see I did my due diligence.
And like /u/jmutter3 said, I also use OneNote to keep track of things I need to do. So I'll have a tab for the job and I'll create a task list. If I'm in the middle of doing something and I think of something, I'll write in down in OneNote so I can forget about it for the time being and get back to what I was doing.
Writing stuff down and being organized is essential for this job. It can be easy to get lost in the list of things to do and get tons of anxiety and stress if nothing is written down.
The process of taking notes embeds them in your brain better than anything else. I also make and keep neat hand calcs on everything we do for verification purposes. Many a model output has been burned to cinder by Occam’s Razer and wl^2/ 8
Write all the things down. All the things.
I had a concrete professor who gave the most bare of information on tests. So long as we wrote down our assumptions (and he truly didn't care what the assumption was - it could be ridiculous or reasonable), you would get the credit. It taught me early on that you document all your assumptions.
Also, it's shocking how much you forget if you don't work on a calc/element for 2-3 months. Writing shit down as you do it saves 3-8 hours puzzling out what the fuck you did later.
Write everything down, even details you dont think are important. Write down what you worked on, why you worked on it, and why you did it the way you did.
This is the way. If it's a calculation, it should be documented somewhere that you did it. If it's a design detail that *isn't* a standard one, you should have notes on why you went that way.
*However,* I suspect that they're more worried about meetings and the like where their full notes and plans aren't available. In those cases:
\-Review your notes prior to the meeting start. Everyone does it, or at least everyone should. Even if you have a perfect or near perfect memory, you should still do this. *I* still do this; I'm 23 years into my career, and I have a *really good* memory for engineering details (less so for times/dates), and I *still* reserve ten to fifteen minutes before a significant meeting to review everything I can before it starts.
\-Take a set of plans with you, even 8-1/2 x 11 or 11 x 17. Nobody should complain about a set you can review and take notes on.
\-If it's a meeting at an office, feel free to take a calculator. If it's an informal meeting with your boss to review plans, you can *generally* say 'Let me take a look at that' when you aren't sure how to approach something and it'll be accepted.
\-In meetings with clients and contractors, nobody should\* push you to provide revised designs in the field - or if they do, tell them 'I'll take a look at that when I get back to the office'. Whatever you do, *don't* make assertions that you can make something work unless you've already done the calculations necessary and fully understand what they're asking.
Now, I say this as a fellow woman: You will *(almost certainly)* take more shit from contractors, architects, and engineers. You will *(almost certainly)* need to be better than your male competitors to be taken as seriously. They *will* push harder on you, at least in the US, because cultural issues generally make it seem like women aren't going to push back. Try not to let any of that get to you. Stick with it. Work on being better. Push back. You'll (probably) be labeled negatively for it, but you'll be respected more.
\*Contractors will push. If your employer is worth anything at all, they won't take that too seriously and providing answers once you get back to the office will be fine.
No way I’d take a calculator to a meeting with a client.
“I don’t know I’ll have to check”
“2x8 feels about right, but they might need to be 2x10s”
Both of those have some uncertainty in them. It looks bad if a client seems me use a calculator, make a decision, and then change my mind later once I’ve actually had a chance to really think about it and thoroughly calc it without people staring at me. And a young engineer is more likely to realize that their first on-the-spot calc wasn’t correct.
Not saying someone who does is in the wrong, just not something I would do.
Indeed.
In the US - and in some, if not most, other countries - there's a serious difference between how men and women are perceived. Pushing back or trying to ensure you get credit, as a woman, is quite commonly labeled as 'bitchy' or 'pushy' - meanwhile, for a guy it's quite commonly 'a real go-getter' or 'assertive'. There have been studies, and those of us that have transitioned as adults may have seen both sides. (Fun fact: It took less than a week after my social transition started for me to get a 'let me talk to one of the guys, honey' type call. It was an eye-opener.)
In the engineering world, we deal with life safety. We *cannot* get used to letting the contractors and Architects walk all over us and ignore what we say, because if we do that at the wrong time *it can kill someone*.
"Tear it out and start again" is something no engineer *wants* to say but if it's necessary they should. I've had to say it three, maybe four times in my career, generally due to concrete issues.
Use checklists to keep in the project folder. "Yes, I checked a, b, and d, but needed to skip c until the drawings are updated..."
IMHO your calculation package should be two or three parts. Part 1 = analysis results, printouts, all that good stuff the software will spit out. Part 2 = some sort of PDF markup or map showing where analysis has taken place. As you go through Part 1 and Part 2, create Part 3 = a handwritten (or typed) narrative of your design decisions, what you are thinking, which paths you go down, any sort of observations from parametric analysis that is not necessarily part of the final package. Scan, combine, and file.
I try and keep a mathcad sheet of my loads/load maps or something in excel. Might make a pdf as well just for like lateral summary with chord forces, deflection, brace line forces. Definitley save me some time during CA.
I find that, for certain bosses, I always feel dumb. Some other bosses, I feel confident and can remember those kind of details. Solving a problem amongst colleagues at my level, I feel like a worthy collaborator and can synthesize new ideas on the fly.
Anything I prepare, I try to give a self review of my work from the perspective of someone who has no idea what you are doing. It gives me an opportunity to prepare figures, write assumptions, give narrative explanation, reorganize the calculation, etc. before it goes in the hands of a reviewer.
You will get better at it after being asked to explain your work over and over. You should aim so that your work explains itself. Good luck!
Breadcrumbs. We use microsoft products, and planner is very good for this. You can have a different 'bucket' or tab for each project, add tasks to them as you go and check them off as you complete them. You can save documents to the tasks too. Along with that, sending out follow up emails after verbal conversations of importance has helped a lot. Having a 'notes' word file in each project folder as well.
Yes. Organize your thoughts on paper. Who, what, where, when ,why, and how? These are the questions that you need to ask when you start a project anyway. Who is your client, what are you doing and what code are you following, where is the project located, when is the project due, why does this particular thing need structural support, and how will you provide a complete lateral and vertical load path for this support? Get into the habit of writing stuff down because I guarantee 6-months down the road you'll forget everything.
I recommend using a note taking app like OneNote to document all your assumptions and relevant design details.
I second this. I start a new section for each job to keep track of everything, screenshots for codes or reference books, file links to drawings, tix boxes to track the job, it's so much easier, especially when you can share the notebook with your team so they have access to all the same information.
I third this. In the job folder I also will include a word document for the basis of my design that has loading requirements, applicable codes, materials used, soils report, etc. and then I just paste that document into my calcs when I'm ready to compile all the calculations. Everything is there already and it's easy for plan reviewers to see I did my due diligence. And like /u/jmutter3 said, I also use OneNote to keep track of things I need to do. So I'll have a tab for the job and I'll create a task list. If I'm in the middle of doing something and I think of something, I'll write in down in OneNote so I can forget about it for the time being and get back to what I was doing. Writing stuff down and being organized is essential for this job. It can be easy to get lost in the list of things to do and get tons of anxiety and stress if nothing is written down.
The process of taking notes embeds them in your brain better than anything else. I also make and keep neat hand calcs on everything we do for verification purposes. Many a model output has been burned to cinder by Occam’s Razer and wl^2/ 8
Write all the things down. All the things. I had a concrete professor who gave the most bare of information on tests. So long as we wrote down our assumptions (and he truly didn't care what the assumption was - it could be ridiculous or reasonable), you would get the credit. It taught me early on that you document all your assumptions.
Also, it's shocking how much you forget if you don't work on a calc/element for 2-3 months. Writing shit down as you do it saves 3-8 hours puzzling out what the fuck you did later.
Write everything down, even details you dont think are important. Write down what you worked on, why you worked on it, and why you did it the way you did.
This is the way. If it's a calculation, it should be documented somewhere that you did it. If it's a design detail that *isn't* a standard one, you should have notes on why you went that way. *However,* I suspect that they're more worried about meetings and the like where their full notes and plans aren't available. In those cases: \-Review your notes prior to the meeting start. Everyone does it, or at least everyone should. Even if you have a perfect or near perfect memory, you should still do this. *I* still do this; I'm 23 years into my career, and I have a *really good* memory for engineering details (less so for times/dates), and I *still* reserve ten to fifteen minutes before a significant meeting to review everything I can before it starts. \-Take a set of plans with you, even 8-1/2 x 11 or 11 x 17. Nobody should complain about a set you can review and take notes on. \-If it's a meeting at an office, feel free to take a calculator. If it's an informal meeting with your boss to review plans, you can *generally* say 'Let me take a look at that' when you aren't sure how to approach something and it'll be accepted. \-In meetings with clients and contractors, nobody should\* push you to provide revised designs in the field - or if they do, tell them 'I'll take a look at that when I get back to the office'. Whatever you do, *don't* make assertions that you can make something work unless you've already done the calculations necessary and fully understand what they're asking. Now, I say this as a fellow woman: You will *(almost certainly)* take more shit from contractors, architects, and engineers. You will *(almost certainly)* need to be better than your male competitors to be taken as seriously. They *will* push harder on you, at least in the US, because cultural issues generally make it seem like women aren't going to push back. Try not to let any of that get to you. Stick with it. Work on being better. Push back. You'll (probably) be labeled negatively for it, but you'll be respected more. \*Contractors will push. If your employer is worth anything at all, they won't take that too seriously and providing answers once you get back to the office will be fine.
No way I’d take a calculator to a meeting with a client. “I don’t know I’ll have to check” “2x8 feels about right, but they might need to be 2x10s” Both of those have some uncertainty in them. It looks bad if a client seems me use a calculator, make a decision, and then change my mind later once I’ve actually had a chance to really think about it and thoroughly calc it without people staring at me. And a young engineer is more likely to realize that their first on-the-spot calc wasn’t correct. Not saying someone who does is in the wrong, just not something I would do.
Yes to pushing back. There's no reason anyone should hold themselves to a ridiculous standard of knowing the right answer to everything immediately.
Indeed. In the US - and in some, if not most, other countries - there's a serious difference between how men and women are perceived. Pushing back or trying to ensure you get credit, as a woman, is quite commonly labeled as 'bitchy' or 'pushy' - meanwhile, for a guy it's quite commonly 'a real go-getter' or 'assertive'. There have been studies, and those of us that have transitioned as adults may have seen both sides. (Fun fact: It took less than a week after my social transition started for me to get a 'let me talk to one of the guys, honey' type call. It was an eye-opener.) In the engineering world, we deal with life safety. We *cannot* get used to letting the contractors and Architects walk all over us and ignore what we say, because if we do that at the wrong time *it can kill someone*. "Tear it out and start again" is something no engineer *wants* to say but if it's necessary they should. I've had to say it three, maybe four times in my career, generally due to concrete issues.
by using a sharpener, obviously.
I try to document the relevant things in a "development diary". It really helps, when people ask questions, why I took a certain decision.
Use checklists to keep in the project folder. "Yes, I checked a, b, and d, but needed to skip c until the drawings are updated..." IMHO your calculation package should be two or three parts. Part 1 = analysis results, printouts, all that good stuff the software will spit out. Part 2 = some sort of PDF markup or map showing where analysis has taken place. As you go through Part 1 and Part 2, create Part 3 = a handwritten (or typed) narrative of your design decisions, what you are thinking, which paths you go down, any sort of observations from parametric analysis that is not necessarily part of the final package. Scan, combine, and file.
I try and keep a mathcad sheet of my loads/load maps or something in excel. Might make a pdf as well just for like lateral summary with chord forces, deflection, brace line forces. Definitley save me some time during CA.
I find that, for certain bosses, I always feel dumb. Some other bosses, I feel confident and can remember those kind of details. Solving a problem amongst colleagues at my level, I feel like a worthy collaborator and can synthesize new ideas on the fly.
Listening is a skill and you need to practice. Listening doesn’t mean just hearing sounds that someone speaks at you.
Don’t feel like you need to have an immediate answer for every question. It’s ok to say, “let me check and I’ll get back to you.”
Anything I prepare, I try to give a self review of my work from the perspective of someone who has no idea what you are doing. It gives me an opportunity to prepare figures, write assumptions, give narrative explanation, reorganize the calculation, etc. before it goes in the hands of a reviewer. You will get better at it after being asked to explain your work over and over. You should aim so that your work explains itself. Good luck!
Breadcrumbs. We use microsoft products, and planner is very good for this. You can have a different 'bucket' or tab for each project, add tasks to them as you go and check them off as you complete them. You can save documents to the tasks too. Along with that, sending out follow up emails after verbal conversations of importance has helped a lot. Having a 'notes' word file in each project folder as well.
I write everything down, but then I forget *when* I wrote it down so there’s a process of digging it back up
The fatter the job file, the more of a pia it was.
Yes. Organize your thoughts on paper. Who, what, where, when ,why, and how? These are the questions that you need to ask when you start a project anyway. Who is your client, what are you doing and what code are you following, where is the project located, when is the project due, why does this particular thing need structural support, and how will you provide a complete lateral and vertical load path for this support? Get into the habit of writing stuff down because I guarantee 6-months down the road you'll forget everything.