
Ask HN: What are the 5 most important techniques you use at job? - xstartup
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.
======
Noumenon72
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.

~~~
riezebos
Are your (not sensitive) AutoHotkey scripts available on Github or something?
Maybe others could learn some neat tricks.

------
matt_s
Do the shit work, and do it well.

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.)

------
Spooky23
Don’t be a dick. When you are tempted to lash out, pause and do something
else, even walk away if need be.

------
gvajravelu
For software developers:

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.

------
blackmagevivi9
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]

5\. Know when to leave work at work.

[1]:
[http://www.brendangregg.com/Perf/linux_perf_tools_full.png](http://www.brendangregg.com/Perf/linux_perf_tools_full.png)

------
ddorian43
1\. Underpromise and overdeliver.

~~~
zhte415
Correctly promise and correctly deliver.

~~~
ddorian43
What you said is _Correctly predict_

~~~
riezebos
Which is probably way more expensive than almost correctly predicting, and
making up for the inaccuracy by underpromising and overdelivering :)

------
badpun
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.

------
trumbitta2
\- Duck ([https://blog.codinghorror.com/new-programming-
jargon/](https://blog.codinghorror.com/new-programming-jargon/))

\- Divide et impera

\- Convention over configuration

\- Rubber Duck Debugging
([https://en.wikipedia.org/wiki/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

------
fenier
Being able to draw flowcharts to explain complex things to non-tech people.

~~~
eb0la
If you're also able to make good drawings, this serves as a quick e-mail
reminder of the stuff you've talked about ;-)

A good capture app (like camscanner or onenote) is great to complement this
superpower.

------
sdfjkl
Keep track of people you've enjoyed working with. They are hard to find.

~~~
agitator
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.

------
outsideoflife
1) Judgement

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

------
itronitron
recognizing and testing assumptions

------
wingerlang
Debugging and being able to communicate clearly with others.

------
matt_the_bass
Listening to other points of view and figuring out how to fit them into what
you want to do.

------
farnsworthy
How about you?

