Hacker News new | comments | show | ask | jobs | submit login
Ask HN: What are the 5 most important techniques you use at job?
24 points by xstartup 5 months ago | hide | past | web | favorite | 24 comments
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.



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.


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


> 3. Notes

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.


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


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


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.


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


1. Underpromise and overdeliver.


Correctly promise and correctly deliver.


What you said is Correctly predict


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


Time constraint.

Features constraint.

Quality constraint.

Pick two.


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.


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.


- Duck (https://blog.codinghorror.com/new-programming-jargon/)

- 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


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


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.


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


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


recognizing and testing assumptions


Debugging and being able to communicate clearly with others.


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


How about you?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: