During our professional career, we learn many things. We forget a lot of them. But there are few techniques which we use every day, they help us excel our job.
This is good advice. It will pay off in the long run. I've learned this throughout my career. It's hard to find people who are on your wavelength, so when you work with them, keep in touch, you may be able to help collaborate again in the future.
1. Keyboard shortcuts. From Win-plus-number-keys to Autohotkey-defined macros. Makes the time between "think of task" and "accomplish task" instantaneous.
2. Notes. From "what was the answer to this bug last time" to "how do you toString an Enumeration?" Increases your memory far beyond human proportions.
3. Abstractifying problems. Don't just google error message, google "Tomcat having trouble compiling JSPs." Don't just be annoyed by scrolling, google "DBVisualizer select database shortcut".
4. Documentation. When you write down "[This class] provides X" and "[This function] accomplishes X" you start to make classes that actually make sense and have a single purpose. When you understand something once and write that down, you don't have to reconstruct your understanding again.
5. Probably taking some time to make your coworkers feel validated and help them out with their own goals.
This also works in code. Commenting why something was done a certain way, and think of yourself 6 months from now when you have to fix a bug but don't remember what the thing was supposed to do.
Just to be fair. There is a way to have all 3. You need to do enough analysis to be completely sure of the time it will take to deliver the features to the quality required. To achieve such an estimate you need to analyse all of the details. The only way I know to do this, is to complete all of the features, and the answer is simply how much time you have spent, with remaining time zero.
I learned this working at a discount store growing up, not in my professional career but it carries forward. No teenage kid wants to mop the floor, but when you do it and do it well you get leeway on other stuff.
Monotonous code changes spanning over 100 files to transition an application off an older platform? Gotta be done. This is where macros and shortcuts and plowing through work comes in. Be a professional, not a prima donna.
You can't just write greenfield new applications using the best tools all the time. It would be like an auto mechanic only wanting to work on engine rebuilds for classic cars and not wanting to do oil changes all week. (I imagine this is the cool thing for auto mechanics, I'm not one though so I could be wrong.)
Emotional detachment. During the low moments, remember that it's just a job and, as long as I'm being paid, I shouldn't care too much about all the bad shit that's going on around me.
1. If you have trouble getting started on a project, just do something really small like add comments to your code. After that, you'll find it easier to do more difficult tasks.
2. git checkout and git diff are two of the best ways to identify difficult bugs. Find the most recent version where the code where the software worked. Find the oldest version with the bug. Diff the two git SHAs.
3. People skills get more important the later you are in your career. At a minimum, try to maintain positive body language and a positive attitude everyday so your coworkers enjoy working with you.
4. Do some parts of your boss's job for him/her. That's a great way for your boss and your boss's boss to realize you're ready for a promotion.
5. Go to industry conferences so you can learn your industry. Not just the technical conferences, but also the business ones. The better you know the business side, the better decisions you can make. The better decisions you make, the more likely you are to be well compensated.
1. Know and understand the problem you're trying to solve.
2. Communicate with your team. Whether it's an annoying problem with the standard library or debugging the impossible, you'll likely to spark new ideas or reconsider things previously overlooked just by talking to someone about it.
3. Document everything and anytime you can. Even if it's just unorganized notes. The longer you wait, the more likely the knowledge will fade. You can always clean it up later.
4. Earn your "Debugging Wizard" title by investing time in learning tools like gdb, strace, tcpdump, perf. Don't be afraid of getting your hands dirty. The more time you spend learning the stack, the more you can get out of it. Also frame this[1]
24 comments
[ 32.3 ms ] story [ 1010 ms ] thread2. Notes. From "what was the answer to this bug last time" to "how do you toString an Enumeration?" Increases your memory far beyond human proportions.
3. Abstractifying problems. Don't just google error message, google "Tomcat having trouble compiling JSPs." Don't just be annoyed by scrolling, google "DBVisualizer select database shortcut".
4. Documentation. When you write down "[This class] provides X" and "[This function] accomplishes X" you start to make classes that actually make sense and have a single purpose. When you understand something once and write that down, you don't have to reconstruct your understanding again.
5. Probably taking some time to make your coworkers feel validated and help them out with their own goals.
This also works in code. Commenting why something was done a certain way, and think of yourself 6 months from now when you have to fix a bug but don't remember what the thing was supposed to do.
Features constraint.
Quality constraint.
Pick two.
A good capture app (like camscanner or onenote) is great to complement this superpower.
2) Prioritization
3) If non-urgent then take the time to make good decisions
4) Discussion in person is best, phone is second best, email is worst
5) Don't underestimate the work other people do, or their attitude to it
I learned this working at a discount store growing up, not in my professional career but it carries forward. No teenage kid wants to mop the floor, but when you do it and do it well you get leeway on other stuff.
Monotonous code changes spanning over 100 files to transition an application off an older platform? Gotta be done. This is where macros and shortcuts and plowing through work comes in. Be a professional, not a prima donna.
You can't just write greenfield new applications using the best tools all the time. It would be like an auto mechanic only wanting to work on engine rebuilds for classic cars and not wanting to do oil changes all week. (I imagine this is the cool thing for auto mechanics, I'm not one though so I could be wrong.)
1. If you have trouble getting started on a project, just do something really small like add comments to your code. After that, you'll find it easier to do more difficult tasks.
2. git checkout and git diff are two of the best ways to identify difficult bugs. Find the most recent version where the code where the software worked. Find the oldest version with the bug. Diff the two git SHAs.
3. People skills get more important the later you are in your career. At a minimum, try to maintain positive body language and a positive attitude everyday so your coworkers enjoy working with you.
4. Do some parts of your boss's job for him/her. That's a great way for your boss and your boss's boss to realize you're ready for a promotion.
5. Go to industry conferences so you can learn your industry. Not just the technical conferences, but also the business ones. The better you know the business side, the better decisions you can make. The better decisions you make, the more likely you are to be well compensated.
2. Communicate with your team. Whether it's an annoying problem with the standard library or debugging the impossible, you'll likely to spark new ideas or reconsider things previously overlooked just by talking to someone about it.
3. Document everything and anytime you can. Even if it's just unorganized notes. The longer you wait, the more likely the knowledge will fade. You can always clean it up later.
4. Earn your "Debugging Wizard" title by investing time in learning tools like gdb, strace, tcpdump, perf. Don't be afraid of getting your hands dirty. The more time you spend learning the stack, the more you can get out of it. Also frame this[1]
5. Know when to leave work at work.
[1]: http://www.brendangregg.com/Perf/linux_perf_tools_full.png
- Divide et impera
- Convention over configuration
- Rubber Duck Debugging (https://en.wikipedia.org/wiki/Rubber_duck_debugging)
- Thinking about a problem while walking or playing some stupid repetitive game like candy crush or powermanga