Job Wanted: Hiring an Employer
I want to thrive. I want an environment where I can thrive.
A bunch of notes on the kind of environment I think I could thrive working within.
AKA, oh god, why do all my jobs suck?
AKA, please god, let them be agile.
AKA, don’t tell me what to, just get out of the way.
new sections: How I’m awesome and how I’m not, and why you should hire me.
This is my attempt at describing what I want out of my career and ways that Systems & Software fit my expectations and can improve toward these ends.
Welcome to The Office of the Future.
I don’t want to be stuck in a job where my work output plummets because I am not being challenged or inspired (or worse am punished for taking initiative).
I don’t want to work at a place where my peers genuinely don’t care about what we are doing and the collective mindset is one of ‘meh’.
I don’t want to be in a situation where I solve a systemic issue with the product, and told that I shouldn’t rock the boat by fixing it (as I would stepping on some else’s code an it would make them look bad for their next promotion).
I don’t want to work at a place that spends most of the time putting out fires because they don’t have the self-awareness or drive to realize that half of them they could have prevented.
I don’t want to work at a place that lacks empathy and design sense, because I am not comfortable with releasing a product that does nothing but frustrate and inconvenience end users.
Most of all, I don’t want an asshole of a boss beating my fellow employees into the ground, creating an environment where I don’t feel safe to voice concerns. I hate that I ended up taking out that stress on my friends and loved ones.
I don’t want to hate my job.
Office Culture
- Type A vs Type B
- Type X vs Type Y
- pull vs push
- rules vs guidelines
- ethos vs convention
- Understands the value of culture in an organization
- encourages offices culture
- and not just through platitudes
- Crunch Time is bad time
- Everything is on Fire
- hard Segregation of business units
- no clue what is happening in other units
- requirements not well defined
- no well defined communication mechanism
- Learning as a core value
- how much money do you devote on purely learning activities
- do you have access to safari?
Environment
- uncomfortable chairs
- staring at a cube
- moved around unannounced / without notice of where or why
- no mouse-pads
- no budget for anything that isn’t ‘cheap & approved’
- Computers with no backup and no battery backup
- Developer expected to deal with resulting disasters on is own time.
- Expected to work on these things in off hours as a matter of due course and not an exception to the rule.
Business Processes
- Agile Kanban DevOps
- Communication Paradigms
- Documentation
- Single Source of Truth
- email is not a document storage system
- Don’t copy around potentially outdated documentation
- Workflows and Procedures are in place to help cope with document hell (see DLL hell).
- bonus points for a document management system and/or training regimen.
- Training is not an ad-hoc after thought,
- and the process is clearly explained
- expectations are laid out so the new employee isn’t left with a mountain of uncertainty.
- Timesheet Hell
- Hours
- Butt in Seat
- Addressing lack of engagement by policing Facebook and cracking down on time entries vs investigating and alleviating impediments and annoyances and trying to work on real engagement.
- Overly concerned with quantity of output over effectiveness innovation/quality
- Metric focused over process focused. Losing the forest for the trees.
- meetings everywhere
- Avoids Crunch Time through proactive measures
- Built in time to refactor code
- Tools and environment
- DevOps as a culture
- https://en.wikipedia.org/wiki/Run_Book_Automation
- Complicated and manual bug tracking
- Painless Bug Tracking http://www.joelonsoftware.com/articles/fog0000000029.html
- Rules vs Guidelines
- internal tools are made to the same level of quality and usability as main product.
- Email is bad
- How do you handle your customers and contacts?
- Push vs Pull task allocation
Code Processes
- joel’s list
- re-factoring
- patterns
- documentation
- expectations of programmer’s experience
- testing
- passion for quality
- Up-to-date practices
- html - avoid quirksmode
- strategy in place to fix quirksmode
- understands quirksmode behavior and has read relevant MSDN documentation on the new way IE browsers handle it.
- KNow what a meta tag is and how to send it down via headers.
- OOP
- functional
- copy and paste considered bad\
- html - avoid quirksmode
- understands, appreciates, and respects principles like
- Don’t Repeat Yourself (DRY)
- Single Source of Truth (SSoT)
- Separation of Concerns (SoC)
- Rule of Three
- The idea of anti-patterns
- code smells
- Cargo Cult Programming
- integration with DevOps
- code review
- time to fix bugs
- other agile processes
- Estimation
- no time built in to improve any of these things
- all expected to be done in off hours and personal time
- build times
- deployment headaches
- Clear and practical Repository workflow
- git?
- Branches + merging features
- Revision control
- Recognition of anti-patterns
- Coding for the lowest common denominator?
Uncategorized Concerns
- pride of workmanship
- pride of my work
- have fun
- see a problem solve a problem
- I AM THE MOST able to see problems affecting my workflow, let me fix them. Get out of my way. Fuck you.
- Customer Focused:
- I don’t care about your revenue, I want to make people happy.
- Revenue goals should only matter enough to keep everyone employed. beyond that its a boat anchor. Its a means to an end.
- Fuck the shareholders, I am not working for them. I am not working for the managers. I choose to work here. The share holders do not “allow me” to work her. They do not keep me employed, because they are not the ones generating our money.
- I am working for my customers:
- people buying what we make.
- Future buyers of what we make.
- My peers who have to use what I make,
- and my future self.
- So fuck you.
- I don’t care about your metrics, I want to produce things that are useful. It doesn’t matter how many tickets I complete, my velocity is for my own benefit to improve. So fuck you.
- I don’t care about your legacy systems and cultural inertia. I want to improve things (so get out of my way).
- Workmanship Pride: I don’t care if a customer hasn’t complained, I want to fix it anyway. I don’t want to file it away into the bug stack of things that will never be fixed because nobody cares. I care. so fuck you.
‘Imagine our software delivery engine as a high-powered jet engine in a fighter aircraft. What if we fail to perform adequate maintenance on that engine—it gets gunked up. What if we don’t periodically re-build parts of the engine? In software delivery we gum up the engine by: ignoring technical debt, delaying refactorings, disregarding automated testing, under-investing in continuous integration tools and processes, and in accepting long deployment cycles. These things are often considered “technical niceties” rather than keeping the engine running at optimum capacity.’ — Velocity is Killing Agility!
interview Questions
- Name three things it takes to be successful in this role
- Name one thing your competition says you do well, and one thing you do not do well as a company.
- what do you like about working here?
- can you tell me about the corporate culture?