Habits/Attitudes Flashcards
First thing you should do after learning something through experience?
WRITE IT DOWN (otherwise you will not remember)
First thing you should do when being GIVEN a project (by boss, client, competition)
ask LOTS of questions (don’t be afraid of sounding stupid). Just keep asking questions until you understand the vision/requirements/options inside and out (saves time in the long run and keeps you from making mistakes)
-communication is key. Anytime they are describing their vision of the design always repeat back to them your understanding of what they said to you so that you can weed out any misunderstandings right away.
-always ask them to verify the information that they gave you, especially if they gave it to you a long time ago. If you are about to use a document that was made based on information that you got from your project lead three months ago, you should ask your project lead to take another look at that document before you use it: maybe right up a few questions about it
-Need to ask if they want development to be more like Agile (focus on prototyping/testing/iteration) or more like Waterfall (focus on design challenges/researching how to solve/avoid them, then do the prototyping at the end)
-agile=each step focuses on a prototype/iteration
-waterfall=each step focuses on a design challenge, researching how to solve/avoid it, and implementing that solution
Most important habit when it comes to assigning a project to others
make sure you are extremely detailed and clear about your vision for the hardware (Clear, Consistent, Concise….. but not boring)
Importance of keeping lists of EVERYTHING you can relating to your project
This includes parts purchased, tests completed, design changes made, SME feedback received. Each of these things you will have to revisit later on when you need some piece of specific information from months earlier
examples: parts you ordered and links to the site/datasheet, testing incidents and the events leading up to them, assembly mistakes/accidents (like dropping a component on the floor before soldering it to the board), SME/mentor feedback, etc.
Importance of generous scheduling
It is unlikely that you will accomplish more than one project-related task in a day. If you look at a low-level decomposition of your MIP, you should budget AT LEAST two days for each task. The fewer days you allocate per task, the more hours you will have to put in for the week. Be smart and balance it with your other commitments/hobbies. Assume each task will take about 6 hours (including process-reviews, distractions, re-work, checking forums, and breaks for the sake of sanity)
-Dont give yourself three tasks in one week unless you’re ready to treat the project like a part time job
-this also helps prevent schedule overruns/schedule crashing
Incorporating relaxation parameters in iterative feedback-based processes
Relaxation parameters aren’t just for numerical analysis. They can be used with any feedback based system (ie PID controllers, back-propegation in machine learning).
Anything in which you could iterate is an opportunity to apply relaxation factor in some form
Getting the desired behavior out of the team
If you have people working under you on your projects you are responsible for their success. You can’t expect them to follow your lead if you do not LEAD.
-if the team is not not “forming” well, things will be even less cohesive in the “storming” stage
-If you want help from the SMEs, ASK them
-If you want people to take charge, PUT them in charge of something that aligns with their int(give them the opportunity to volunteer)
-If you want people to discuss the project, set up a meeting. If people are new to the project, set up a welcome/kickoff meeting to help get people invested, get them up to speed on what we’re building, get more input for deriving requirements, and give you a sense of what areas/tasks those people might want to lead or take ownership of.
Getting the desired behavior out of the team
If you have people working under you on your projects you are responsible for their success. You can’t expect them to follow your lead if you do not LEAD.
-if the team is not not “forming” well, things will be even less cohesive in the “storming” stage
-If you want help from the SMEs, ASK them
-If you want people to take charge, PUT them in charge of something that aligns with their int(give them the opportunity to volunteer)
-If you want people to discuss the project, set up a meeting. If people are new to the project, set up a welcome/kickoff meeting to help get people invested, get them up to speed on what we’re building, get more input for deriving requirements, and give you a sense of what areas/tasks those people might want to lead or take ownership of.
The importance of having deadlines
It’s important to set deadlines both for the small granular steps that you’re working on in the near future AND major milestones and gateways for your project.
Project prioritization
Start with the SIMPLEST project on your list, the one that has the lowest learning curve for you.
As you complete those projects take the knowledge that you learned from completing those projects and apply them to other ones.
Project peer reviews
Helps keep you accountable by setting a fixed date and time for you to present what you’re working on to somebody outside the project. This can be SMEs, but it can also just be friends and family (this was extremely helpful on Terminus with the NASA reviews)
Helps mitigate the effects of the “adjoining” phase of a project. You need to reward yourself for making progress so that you don’t lose interest, energy, or focus
Importance of celebrating project milestones
Helps mitigate the effects of the “adjoining” phase of a project. You need to reward yourself for making progress so that you don’t lose interest, energy, or focus
Importance of being patient with the SMEs
They have much higher priorities than your project, including have jobs/lives/families/emergencies/concerns/projects of their own.
-If you don’t hear back from them, be patient. Follow up when appropriate
Four project related skill categories and why they’re important
- Analytical knowledge
- Analytical experience
- Technical knowledge
- Technical experience
Realistically you should have all four. Be honest with yourself about which skills you bring to the table and get assistance from people to help fill in the blanks
-Need to understand the difference between familiarity and mastery (particularly in analytical, just because you know what something is and how it works doesn’t mean you can actually apply it)
-Case/Examples: writing a program to calculate the transfer function for a filter
-Analytical knowledge example: knowing that impedance is a complex number, and how to represent it as a complex number in the equation
-Technical knowledge example: knowing how to represent complex numbers in your code
-Technical experience: Being able to look at the code and know what to look for
-Analytical experience: Being aware that the most likely reason that it doesn’t work is because impedance is not represented correctly
Analyzing the advice you’re given on a project
Advice from non-experts/non-professionals (and by extension strangers on the internet) is not good advice. Only trust SMEs and mentors on those topics in which they have professional experience AND education (lots of ameatures out there who can speak confidently and intelligently on a topic, but don’t actually know what they’re talking about about)
-If someone is an expert in embedded systems, you should not just blindly accept what they have to say about power electronics (and vice-versa)
-that doesn’t mean you should totally ignore what they have to say on those other topics, their opinions can give you ideas of things you can ask a SME about… But you need a second opinion from someone who has both worked professionally it has formal education in that area
Accurately assessing your skill in a given area
Unless you have experience doing something professionally (meaning that you did that thing every weekday for years) you cannot assume that you are actually good at it
-be honest with yourself about what you ACTUALLY did during your employment (THOSE are your real skillsets)
-this concept applies to others as well: don’t trust the advice of ameatures
The importance of a “good enough” attitude
1) A SME-validated “good enough” option can save you from doing too many trades
2) Promotes anti-perfectionism
3) Prevents the OAT phase from slowing you down
WARNING: some requirements, like safety, cannot be approached with a “good enough” attitude
Helps you avoid perfectionism.
Sometimes it’s best to settle for the good enough solution to a problem you’re having, (as long as you can get validation that it is in fact good enough). This is because an attempt to fix the problem further can actually make it worse in ways you cannot foresee
How important is it to document your code?
-not having enough documentation WILL cause confusion when you revisit that code in the future.
-As a general rule, your total number of “lines of code” should be a 50/50 mix of comments and commands (No, that is not excessive. You REALLY need to spell it out for future-you)
-Write down what the code of for, why you chose to write it the way you did, and what you have learned from it
-This is especially true if you are using the code as a learning tool to help you simulate/visualize concepts
-comments should also include the content of any external files you will need to run the code
Trying something for the first time
If it’s your first time doing something, never ever be afraid of doing it poorly. If you fall into perfectionism, you risk never even starting, let alone actually getting it done (just like the Jupiter pcbs). Just do it the best you can and then ask for feedback.
- this also applies to granular attention to detail. Remember Jackson Pollock (he never would have started painting if he had obsessed over detail)
Importance of “project continuity”
Continuity is important. Don’t leave gaps in your timeline (even if it’s just a month). ALWAYS have an ongoing hardware/software project.
- Research and PowerPoints do not count
- If you won’t be buying parts or writing code, there’s no project
*Know exactly what you’re going to be working on both this month and next month to work towards a successful IA&T
How to effectively “question everything you know”
Unless you’ve had some of it validated, question everything you know. All your existing knowledge and assumptions fall into three categories:
- True, but incomplete (needs context or clarification)
- True and valid
- Untrue
*This also applies to assumptions and even excuses. Need to carefully evaluate what is in your mind with this framework
The importance of blocking out the holidays when project planning
When working on a team (especially government or school) just write off the last 6 weeks of the year. Nothing productive is happening during that time.
- Do not include a phase/gate transition during that time. If people need to scramble to catch up on work that hasn’t been done before the review, they won’t have anyone to work with because no one else will be working (CRMS fall 2024)
What to do to get ready for taking a break on a project
1) Set a fixed time limit. Otherwise you risk that break going several times longer than you thought and you might never get back to the project
2) If you are on a project, and you know you’re going to have to take a step back and not work on it for a while, write yourself a mini onboarding document to explain where you were, what you were doing, and where you were going that way you can get caught up as quickly as possible upon your return. Try to anticipate any questions that you might have.
Importance of sending emails to people asking for documentation and resepurces before starting a task
If someone else is in charge of the project, and you are assigned a task, more often than not you will not receive the documentation or the resources that you need to complete that task. The best way to ask for it without sounding like an idiot is to say that you want to ensure traceability
