-
Notifications
You must be signed in to change notification settings - Fork 0
/
hn-notes.txt
128 lines (66 loc) · 7.15 KB
/
hn-notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
" Set text width as 72.
https://news.ycombinator.com/item?id=36056299
Ask HN: How do you not take criticism of your work personally?
The pro tip is to attach your self worth not to your skill, but to it's first derivative!
That way any criticism that helps you improve your game, no matter how unpleasantly delivered, is a power up.
I say it glibly, like it's easy, but it works if one can internalize it.
=
If you do have to reply, don’t do so immediately. Let it marinate and respond when your initial feeling has subsided. That allows you to get some emotional distance between yourself and your work, thus seeing (and fixing) the problem in the thing not yourself. Waiting has the secondary effect that another person may reply in the interim, shifting the burden away.
When you feel bad, stop to think. Observe your own reaction and calmly try to realise why you’re feeling that way and what’s your goal. The introspection alone can make you see that the situation is unimportant and thus taking it personally is disproportionate.
=
Another good approach: Write down that email/ message in a text editor but just leave it there for a day.
Often, I'd realize that I don't want to send it at all. The emotion was processed and now it's fine.
Sometimes, there is a valid point (e.g. because someone was rude in tone) and I'd just give that as feedback in a non-violent manner.
=
At some point, I realized that there's a disconnect between "me" and "my work".
My work is a result of circumstance, like, what my mood was when I did it, how well I know the particular domain, if I've seen solutions to similar problems before, what tools were available and understandable to me at the time.
In other words, the quality of my work depends much more on what the particular task was, than on some inherent quality within myself.
So, try not to let it influence me either way, to not feel some unjustified pride that I made something "difficult", or shame that I couldn't manage to do something "easy".
One liberating tactic I employ, is that I clearly announce when I've messed up, and I'll be the first to do it, and usually with a joke.. "Yeah, so that amazing queue we got up and running last week, I took the liberty to totally mess that up, I learned a lot about how not to do it, I'll eventually learn how to do it right, no worries, I'm working on it." This takes the pressure off, people know it's broken, who broke it, and who's fixing it, and they expect that I come for help if I need it. One thing I don't do, is say sorry, I'm not sorry, this is my job, we do software development, we break stuff, we make errors, and I'm not sorry about it.
=
In art school, we spent a lot of time learning how to give and receive critiques, because the fastest way to improve was to try frequently and critique often.
You learn very early to divorce your ego and sense of self from your artworks and embrace every attempt as an opportunity to improve towards an ideal you can never reach.
You also learn how to give meaningful criticism without being an asshole.
Writing code is very much the same.
Unfortunately, most software engineers haven't been to art school and have no formal training in how to give and receive useful feedback.
I recommend reading Art & Fear: Observations On the Perils (and Rewards) of Artmaking. It's a good book that helps you build a healthy mindset towards growing as a creative:
=
me:
Guess everything depends on the context, however the context can be misunderstood.
The best way is to take a break, this makes it easier to evaluate the information in it's proper context.
=========
https://news.ycombinator.com/item?id=34484710
Ask HN: What is your experience in tech consulting?
Niches = riches.
You want a super-tight thing that you do (e.g. "I fix performance issues for large NodeJS code bases", or better still "I write tooling to measure performance hotspots in NodeJS code bases".)
Despite this sounding like cutting off potential customers, it doesn't work that way. Customers will reach out to you with some generic work that they want done "because I know you know NodeJS" even when you say you specialise in something.
A good first book to read: "Book yourself Solid" by Michael Port.
===
...
- Your name is your bond. When people learn they can trust you, even in just a handshake (remember: contracts!) they happily recommend you to your friends
- Digitize it all. Do everything in your power, pay for every web service that makes sense, to reduce your overhead. I was incredibly happy to pay for receipt scanning (shoeboxes), book keeping / invoicing, and accounting (xero). Most people view this as an expensively monthly cost - which it is at the beginning. It will also, eventually cost less than an hour of your consulting time. Scale.
- Never price at the top of the market. It's better to be 100% busy at 80% of the fee structure, than it is to be 50% busy, at 125% of the base rate.
===
20+ years since I started my firm, we are very successful and I love our team and our work.
Few points…
Word of mouth is best advertising.
Prove yourself trustworthy and honorable, there are still assholes who will try to take advantage of you but on balance, this will pay off over time.
Don’t work for free. If companies want you to work because it will look good for referrals or something- run.
Don’t work for equity or revenue shares without some cash as part of the deal. Cash is skin in the game, it makes everyone act differently.
Treat your team better than you wish you were treated - they are your most important relationships.
Be willing to fire clients.
Fancy contracts are a waste of time, if you ever get to the point after work has begun that you are talking about wording in a contract - you already lost.
Lastly…learn to delegate, I spent way too much time doing too much of the work myself- sharing the load is a superpower.
OP or anyone else thinking of doing this, feel free to reach out for a longer chat on the topic.
===
Niches = riches.
You want a super-tight thing that you do (e.g. "I fix performance issues for large NodeJS code bases", or better still "I write tooling to measure performance hotspots in NodeJS code bases".)
Despite this sounding like cutting off potential customers, it doesn't work that way. Customers will reach out to you with some generic work that they want done "because I know you know NodeJS" even when you say you specialise in something.
A good first book to read: "Book yourself Solid" by Michael Port.
====
I run a consulting firm.
Get one client. Do an amazing job. Use that to tell other clients what you do.
Be specific. Most people outside tech have no idea how it works. Tell them what they will get.
Increased sales, reduced costs, better productivity. Whatever it is you do, forget about the tech and talk about the benefits.
Get your elevator pitch right. Mine is "I help businesses fix their procedures". People then say "You know, I could introduce you to my friend...."
Business first, tech last.