

Ask HN: How to move from developer to support role? - unchabon

I&#x27;ve worked for a bit more than a year as a developer but recently transferred to a customer support role which still requires dev skills. I seem to be managing fine, but I&#x27;d like to have another resource besides experience to learn from. As a developer, I was used to having many reputable sources of information and experience at my disposal that I could rely on, such as official documentation, StackOverflow, HN and so on. Unfortunately, with &quot;customer success&quot; being as broad as it is, I see there is a lot more snake oil and buzzwords being thrown around, with no clear sources of truth or at least objectiveness to be found.<p>Has anyone else been in a similar situation (moving from dev to support)? What&#x2F;where did you learn from, besides intuition and experience?
======
aaronchall
Ah, Devops! Yes, I've been in a similar situation. I set up a support desk,
writing documentation and certification tests for the new platform at my firm
(also providing them a portal and a nifty sentinel program that got shelved)
before moving to an architecture team. I was pretty much lead technologist for
them. Here's the surprising part:

You make it up as you go.

OK, you don't really make it up. You take the lead, find out what the business
needs and stakeholder needs are, attempt to apply relevant principles (which
you'll discover as you go) to their logical conclusions, and yield only when
there's pushback from your boss.

I was frequently given the responsibility of making people comply with the
rules while being forced to ask for their permission as we went. I was nice. I
was mean. I cajoled. I coerced.

Principles - all and sundry were applicable. I applied principles from
business to technology to morals and ethics.

Principles of Unix Programming:
[http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond.E2...](http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond.E2.80.99s_17_Unix_Rules)

The Principle of Least Privilege:
[http://en.wikipedia.org/wiki/Principle_of_least_privilege](http://en.wikipedia.org/wiki/Principle_of_least_privilege)

Dr. Dobbs has an article about effective devops -
[http://www.drdobbs.com/architecture-and-
design/top-10-practi...](http://www.drdobbs.com/architecture-and-
design/top-10-practices-for-effective-devops/240149363) \- and IBM has a
slightly different view:
[http://www.ibm.com/developerworks/devops/practices.html](http://www.ibm.com/developerworks/devops/practices.html)

In general, Google for "best practices", "principles", "devops" and related
terms. Always do the right thing, especially when your co-workers want to take
the easy road, you'll set yourself apart from them. When asked to push code,
read it and know what it does. When asked to review permissions changes,
scrutinize it carefully, and ask questions. Write documentation. Know the
process. Talk to the stakeholders. Update the documentation. Ask how it can be
made better. Think hard, and answer that question.

~~~
aaronchall
Has anyone read this?

------
akulbe
How ironic. I have the same question, but in reverse!

