
What are the biggest headaches as a developer or systems admin? - edwcar13
I don&#x27;t have much experience in my new career and am wondering what I should learn or brush up on. I want to either avoid or be able to maneuver quickly around these headaches.<p>Essentially you can blow off some steam here about your day to day tech troubles. :)
======
skiltz
Not having a decent mentor. Self taught working as a solo developer. Don't
know what I don't know. If I had someone to peer review code or bounce idea's
off then I could have progressed a lot faster. If I could start again I would
join a development team and learn from developers with a lot more experience.

~~~
twoquestions
I keep hearing about how great mentors are, but what's in it for the mentor?
Why should someone who knows what they're doing provide such a valuable
service for someone who can't pay them back?

In older times, tradespeople literally got a live-in servant for the trouble
of teaching them, but other than college tuition I haven't heard of a good
compensation model for mentors.

~~~
NetStrikeForce
In many companies that's part of the job description (to be a mentor for
others), so I'd say there's money and career in it.

------
cweiss
Knowing who to talk to about a given issue (for a large company). Since you
say "new career", I assume you're starting a new job somewhere. I work for a
fairly large organization that's heavily silo'd with regards to
responsibilities. When something goes wrong, I often have to work with 4 or 5
departments, each of which has some folks who are helpful and folks who are
'blockers'. Figuring out who the right folks to talk to for a given issue can
make the difference between solving something in minutes or hours (days).
Likewise, making sure folks know my responsibilities and when to bug (or, more
importantly, not bug) me.

Know your domain tools and always be looking for new (to you) ones. If you're
new and in the linux sysadmin domain, you'll be doing a lot of "oh wow, I
didn't know about XYZ". Find the old stuff that's been around forever (and
likely installed everywhere) before jumping on the new hotness that'll require
big changes to your systems to install. I like HN for some of this. Read the
comments for the 'vim/tmux/bash/cron/git guide' entries that get reposted
every few weeks. I guarantee somewhere in the comments, you'll find something
you didn't know that'll help.

Scripting tedious tasks is huge. Learning the bits of
shell/perl/python/ruby/whatever that interact with the tasks you do day-to-day
can be very beneficial. Automate all the things.

------
fazza99
Everythng that's repetitious and error-prone: Manual migrations of old
physical servers, disaster-recovery, managing legacy infrastructure. Luckily,
most of these have been obviated by the cloud, thank god. I became a sysadmin
to work on interesting projects, not to endlessly reset AD user credentials.
Granted there is a level of repetition in any job, but when the process
becomes to the job, it's time to automate.

------
malux85
Management having no idea about what the machines can do (even conceptually) -
authorising, signing off and scheduling literally impossible work.

------
cdennison
My experience is that most technical issues have solutions (e.g. see Working
Effectively with Legacy Code), but there's now way to fix bad (project)
management other than a revolution.

I agree with other people that you can mitigate the pain of bad management by
doing things like 1) Write high quality code from day one 2) Automating
deployment 3) Minimizing technical debt 4) Doing "spike" when asked to do
something new so you don't give a bad estimate.

[http://programmers.stackexchange.com/questions/122014/what-a...](http://programmers.stackexchange.com/questions/122014/what-
are-the-key-points-of-working-effectively-with-legacy-code)

~~~
edwcar13
Never heard os spike. Most certainly looking that up. That's k you.

------
executesorder66
My biggest frustration at work is having to use windows. Mainly because of the
MS Exchange mail server. I could use webmail on linux, but then I don't get
the calendar reminders and I'd be late for everything. There is also one or
two admin applications that require Internet explorer(WTF this is 2016) So if
you could learn how to force your company to ditch anything related to
Microsoft you will have the time of your life.

~~~
NetStrikeForce
You don't have to use Windows. You can use OS X, Android or iOS. All of them
have clients that can pop those meeting reminders for you.

So I guess your biggest frustration is not being able to use Linux? Meeting
reminders is a poor excuse to not do it. Come on :-)

------
serpix
Traditional infrastructure. after doing a few projects with cloud based
deployment I am now at a loss of words for the frustration of having to order
a server, wait for it for weeks. Get it with insufficient ram, firewall locked
out, it's shared by twenty other developers and I have to deploy using chef
because that's what we always use.

All this is so behind the times the waste of time and money is appalling.

------
shoo
working on systems that don't have automated tests, and are designed such that
adding automated tests is not easy.

you don't have to practice TDD, but it is a fantastic idea to add automated
tests early on when the architecture of your system is still fresh and
changeable.

projects that don't consider "testability" as a requirement tend to produce
system architectures that are not testable.

~~~
dozzie
Projects that consider "testability" as a requirement tend to produce systems
that are perfectly testable, but this is orthogonal to whether the
architecture makes sense and can be composed with something else.

~~~
shoo
maybe so. i guess my comment is a reaction after seeing a few projects where
it is an afterthought.

i assume by "orthogonal" you mean independent, i.e. just because a system is
testable it does not mean it necessarily has other desirable properties.

~~~
dozzie
Actually sometimes being easy to run tests on harms the code, because the code
grows its surface just to plug in more tests, or the author stops at "I can
test it, so it's good enough" instead of ensuring the architecture and/or
interface is so simple that it can't ever possibly fail.

------
adnansaleem
When you have to Debug some one's shitty code...

~~~
bitshepherd
Look at it from the other side. They're debugging your shitty code, too.

------
mcdevhammer
Change tickets. Change tickets for everything.

------
edwcar13
Thank you all for your feedback this was great!

------
erac1e
Saturday mornings after beer o'clock turns into an all nigher

------
bjourne
People.

------
max_
Mainly authentication credentials.

Managing SSH keys, and Passwords

------
pandeyalok
dealing with unmaintainable coding experts

------
mvdwoord
People.

