What are the biggest headaches as a developer or systems admin?
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.
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. I cannot upvote this enough, I am in the same situation, whatever you do try to always work with people smarter than you that you can learn from, you will get better so much faster. I'm same and now I'm in middle of changing my job from full time to contracting and this makes me wonder if I should go work in better team or I should stick to the more money I can make from contracting.
Any advice ? I've thought of this a bit in the context of more senior developers. One of the questions I asked my friend was "who the heck do I go to when I am the senior architect/dev and need help with X technology?" I wonder if there is a site or product out there that lets me help others with X technology and I some sort of karma/credit and other people can help me with some tech they know really well. Maybe I should build it :) 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. 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. 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. 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. Management having no idea about what the machines can do (even conceptually) - authorising, signing off and scheduling literally impossible work. 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... Never heard os spike. Most certainly looking that up. That's k you. 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. 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 :-) you can follow this guide: http://nknu.net/ubuntu-14-04-exchange-configuration-thunderb... You'll have exchange setup on Thunderbird with email & calendar. They recommend using Pidgin for a lync replacement, but I use Sky. And then the address book might require saying you have a mac (to your it department) and getting some specific info or dsquery'ing of your current working windows desktop. To use internet explorer for your 1 or 2 admin applications just dual boot so that you can always use windows in a pinch. 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. 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. 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. 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. 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. When you have to Debug some one's shitty code... Look at it from the other side. They're debugging your shitty code, too. Change tickets. Change tickets for everything. Thank you all for your feedback this was great! Saturday mornings after beer o'clock turns into an all nigher People. Mainly authentication credentials. Managing SSH keys, and Passwords dealing with unmaintainable coding experts People.