I don'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. :)
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.
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.<p>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.<p>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.
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.
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.<p>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.<p><a href="http://programmers.stackexchange.com/questions/122014/what-are-the-key-points-of-working-effectively-with-legacy-code" rel="nofollow">http://programmers.stackexchange.com/questions/122014/what-a...</a>
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.
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.<p>All this is so behind the times the waste of time and money is appalling.
working on systems that don't have automated tests, and are designed such that adding automated tests is not easy.<p>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.<p>projects that don't consider "testability" as a requirement tend to produce system architectures that are not testable.