
Ask HN: Insecurity as IT worker - AliceInUnixLand
Hello, some thing bother me. Please do not make any assumptions about me from the username.<p>I have been around IT +&#x2F;- professionally for some 6-7 years including student work. My experience has been a lot of everything. Some electronics engineering, some embedded development, some simple web fronts and backs, some desktop UI, some server administration. For the last few years I have been working as &quot;the technical one&quot;. Set up services, updates, applications, dig through logs&#x2F;code to find technical reasons, prod things to move, clean&#x2F;move&#x2F;dig through data in DB or write offline script, write some integration middleware, maintain servers (10+ clusters of multiple VMs). A little bit of everything. Maybe rather close to what DevOps should be, or at least how I imagine the role.<p>Therefore, I am insecure. Time-wise I should have sizeable experience. I can drop into many non-purely-coding fields and have some idea what is going on. I can read documentation, StackExchange, Google. Though, browsing job ads make it look like that even junior programmer is required to have production scale experience with multiple frameworks, DevOps are required to have production experience with various monitoring&#x2F;logging&#x2F;orchestration&#x2F;virtualisation&#x2F;cloud-solutions&#x2F;continuous-whatever systems. All I can say is that I am familiar with some tools and know the concepts. I know that I cannot drop into a role and magically make things work. It can take months to actually figure out and cram into my skull how various subsystems interact and interoperate, relations in extensive DB schemas, what actual developement&#x2F;QA&#x2F;deployment processes are. And I read online how person X just brushed over documentation and got things running solid, came to hackaton and developed out of thin air what startups with teams release crappy versions of in several months. And therefore I am feeling insecure and doubtful in the job market. How can I overcome this?
======
dozzie
Talk with other people in your field (real people, not cherry-picked histories
that could be made up or at least heavily colorized), and _not only_ the ones
that _talk_ at conferences. You'll realize that your peers know much less and
are much less capable than you attribute to them.

> And I read online how person X just brushed over documentation and got
> things running solid,

They didn't. It took them a significant amount of time, it's just very hard to
record and later describe this process of trial, error, and backtracking. It's
much, much easier to polish the procedure for final publication.

> came to hackaton and developed out of thin air what startups with teams
> release crappy versions of in several months.

This "thin air" took significant amount of preparation. The hackaton product
is bug-ridden, resource-hungry proof of concept that can't serve more than a
handful users, crashes badly on slightly invalid data, and cannot be
maintained in production (data backups? recovery after server crash? user
management? logging? status monitoring?).

Not to mention that topics for hackatons are chosen specifically to suit well
the form of making a PoC in two days. _Useful things_ usually do not fit this
time frame.

------
db48x
Job ads are a particularly annoying form of lie. Someone sat down and wrote
all the things they wish one of their employees knew (but that they don't want
to pay them to learn). It's not a very helpful source of information.
Hackathons are a pretty bad source of information as well; they haven't taken
the time to do any real engineering. Anyone can do a prototype in a weekend,
but a prototype is not a product.

Instead of worrying about the job market, be a consultant. Talk to the people
who actually care about the things you're going to develop, hammer out a
contract with an estimate and a nice price tag, and then deliver it. That sets
up a nice feedback loop: agreement, delivery, check, repeat.

Another thing to do is to specialize. The primary skill of a generalist is to
learn continuously, and to learn whatever is needed to get the job done. This
is a great skill, but it's a trap to only ever learn things shallowly. You
need to learn at least one thing deeply so that you can become an expert in
it. You'll be able to do more work in the same amount of time, while still
delivering quality results. Since you'll be satisfied and motivated whenever
you deliver quality work, this will go a long way to ensuring that you're
satisfied and motivated all the time. Your level of security then becomes
obvious, and you can stop worrying about it.

For example, my own speciality is Firefox. I don't know everything there is to
know about Firefox, but I know a lot. Firefox Addons, Firefox embedding,
desktop apps built using Firefox, even some of the internals. I take other
work too, but Firefox is what I really enjoy; the other stuff is just to fill
the gaps, keep me thinking, and provide a change of pace.

------
reacharavindh
Not an answer to your question, but just wanted to say I'm in a similar boat
as you. I was working for a big tech company doing what I call a "non-core
programming" \- analysis role. I was neither a systems programmer nor a math
wizard. I knew enough CS background to understand the problem domain very
well, and enough Python/stats/pandas/bash fu to arrive at useful answers. But,
I didn't see a career in it. I'm now a sysadmin for a research centre and
found my lost love for building and maintaining clusters. I don't know if I'd
become as smart as some of the people I read about & admire on HN, but I
stopped worrying too much and started focussing on the little things. I'm now
designing a better version of our research cluster, learning a load of things
along the way. Hopefully, once I'm confident enough in myself, I will work on
my ideas rigorously and build useful products.

TLDR; I stopped worrying too much and trying to keep things simple, and learn.
Don't quite know if my words will be useful to you.

