For a few days after moving my blogs to self-hosted WordPress, I was seeing somewhat frequent restarts of the MariaDB container. I didn’t see any real indications as to the cause, just a few sql formatting warnings.
I added swap to the host vm, thinking that it may have been memory pressure causing issues. Since I have done that, the problem seems to have gone away. EasyEngine recommends adding swap and a few other tuning tweaks if this problem recurs.
I’ve had a number of domains which I had hosted blogs on in the past and that have been lying fallow. I was pretty happy hosting them on wordpress.com, but the number of sites and the monthly cost per site were just too high to justify the cost of WordPress hosting for sites that were simple “for fun” web publishing. I’ve made several attempts at various static-site rendering solutions or Netflify JAMstack implementations, and while I think they are truly awesome, they also require a lot of development and implementation maintenance (tooling versions are constantly evolving and there isn’t much guarantee that content will continue to work over the long haul). I’ve also lost content in previous engine transfers (mostly from exporting from hosted blog platforms that ran out of VC money), so I suppose I’d rather stay with WordPress(.org) if I can. Eventaully someone may create a static rendering pluging for the WordPress engine and hosting this will all be easier with free or cheap static page CDNs and the engine hosted privately, but so fare those solutions do not seem fully baked and well supported.
Essential System Setup
I started with a 1gb Digital Ocean droplet with Ubuntu 20.04 installed and weekly backups configured. I set up a new ssh key and added a ssh config file entry for connect to the host:
The host needed initial package updates:
apt install net-tools
I changed the ssh port as well, to reduce amount of useless security probing and port scanning. This isn’t a huge security measure, but I understand that there a lot of unsophisticated nuisance attacks.
# Uncomment and modify "Port" directive
service sshd restart
This required an update to my ssh config file as well.
The basic install for EasyEngine 4 is a simple bash script download and execute. Before installing, there were 23gb free on my system drive. EasyEngine installs docker and pulls several images.
wget -qO ee rt.cx/ee4 && sudo bash ee
After this install I had 19gb free on my droplet drive.
Configuring a first site and importing from Tumblr
EasyEngine makes setting up a new site a single line command. I want to set this up with LetsEncrypt SSL, so the first step is to get DNS for joshrivers.me and www.joshrivers.me pointed at the IP address of the droplet. I’m disabling Cloudflare proxying here because it currently appears that this conflicts with getting LetsEncrypt setup.
With this configured, setting up the basic site is a single command:
ee site create joshrivers.me --wp --ssl=le
After a few minutes, and entering my email address for certificate renewal notification emails, I had a functional site. I verified that redirect-to-https was configured with curl -v http://www.joshrivers.me and the web server is supplying 301 redirects to the https version of the site.
First step after creating the new site is to login with the generated admin credentials and change the display name of the account (no point in having a randomized username and printing it on every web page).
Outbound email did not work out of the box with the builtin postfix. Trying a test send from the command line gave an error: server message: 451 4.3.0 <my address>: Temporary lookup failure. Installing cli tools into the postfix container shows that name resolution is working from there. It appears there is a configuration error with the dockerized postfix where email fails when the domain matches the hosted site. The errors go away when attempting to deliver to a different domain. Frustratingly, I still don’t see any email delivery at this point. Those emails may be being blocked due to my SPF configuration for my domains. There was a useful fix described on the community forum, but I still have no mail delivery.
Ultimately, I don’t think I need transactional emails from wordpress, so I’m going to leave it alone for now. I can dig at postfix and SPF later if it seems important.
Further settings to update:
Day and Name Permalinks
Next I imported my old Tumblr Blog, which required removing the custom domain mapping in Tumblr and using an OAuth login. After importing I verified comments were disabled on all the old posts. And I deleted the “Hello World” post. I used a simpler theme for joshrivers.me than the default WP theme. It could use some work, but it is fine as a start, and at least as decent as my Tumblr theme was. Next I set up Jetpack.
Imports fron WordPress.com
For each of my additional sites, I ran through this outline:
Importing with media import seems to work seamlessly. I got an error due to an attachement from my long ago import when I got onto wordpress.com but I don’t think anything was lost there.
Deactivate Importer Plugin
Change default category
Added this to CSS to stop showing the (disabled!) comments link:
display: none !important;
Using the DB shell instructions from the EasyEngine Handbook, I was able to change the admin email address:
SELECT * FROM wp_users;
UPDATE wp_users SET user_email = "<my_address>" WHERE user_email="firstname.lastname@example.org";
SELECT * FROM wp_options WHERE option_name="admin_email";
UPDATE wp_options set option_value = "email@example.com" WHERE option_name="admin_email";
I next tested this with the outbound email instructions. Still no mail delivery. This is bugging the heck out of me, but I also can’t think of a single reason I need to send emails from my blog server, so I should really just leave it alone, right?
In my experience, very few people understand the techniques, limitations, and implications of encryption (and the attacks upon it). I work with, and have worked with, a large number of talented software engineers and system administrators, and for the most part their understanding of this topic is only a surface understanding. The public image of encryption and hacking on CSI, and Mission Impossible only makes it worse. I don’t expect people to undestand this technology and its complexities. It’s too hard. Just relax and understand that you have no clue, and most likely no normal manager, politician, or non-specialized technologist does either. It is VERY complex.
What is not complex is the understanding that encryption is important to you. Personally, economically, socially, and politically, knowledge is power and control. We already live in a world where powerful people and organizations are allowed to keep more secrets than individuals. A world without legal strong encryption could easily become one where the powerful have unlimited secrets, and you are allowed zero.
It makes me very glad to see Apple and Tim Cook fighting the police and the President for your right to have some privacy in your life.
Apple CEO Tim Cook lashed out at the high-level delegation of Obama administration officials who came calling on tech leaders in San Jose last week, criticizing the White House for a lack of leadership and asking the administration to issue a strong public statement defending the use of unbreakable encryption.
The White House should come out and say “no backdoors,” Cook said. That would mean overruling repeated requests from FBI Director James Comey and other administration officials that tech companies build some sort of special access for law enforcement into otherwise unbreakable encryption. Technologists agree that any such measure could be exploited by others.
Apple — and Tim Cook, specifically — is the only major tech company currently defending encryption against intrusive surveillance to this degree. Every other company is either open to compromise publicly, has privately compromised, or has failed to take a firm stand.
This came up during last night’s Republican primary debate — not about tech companies refusing to allow backdoors in encryption systems, but about Apple specifically. Tim Cook is right, and encryption and privacy experts are all on his side, but where are the other leaders of major U.S. companies? Where is Larry Page? Satya Nadella? Mark Zuckerberg? Jack Dorsey? I hear crickets chirping.
Real leaders have courage, and on this very essential issue — in the face of fierce political pushback from law enforcement officials — only Tim Cook is showing any.
I’m starting to get the hang of the Docker thing. I’ve been doing it _just barely_ long enough to see some change, and I’ve read material over a longer period. I think it’s important (from an architecture planning perspective) to constantly keep in mind that Docker is a set of very rapidly changing abstractions over a set of solid long-term base functions. Often the abstractions really suck for a while, since they haven’t truly figured out what things are going to look like in the end.
So we have lots of instances of:
In the past we used this crazy workaround for a feature being missing <——> now we have a half-baked abstraction that may or may not be better than the crazy workaround <——> when we get to use docker 1.9 (or 2.5 or whatever) it will make sense in this way better way.
Logging is one of those that is probably pretty solidly fixed in docker 1.9.
In networking, the new shape in docker 1.9 looks awesome, so by docker 1.11, it should be solid.
Volumes are just starting to get a real picture laid out for us.
So for volumes, we have four ways that docker manages volumes:
Host mount (i.e. -v /home/josh/folder:/dock/app/folder): this completely makes sense, and is solid. The only problem with it is that it doesn’t allow any sort of clustering tools to manage/move the containers around, since the volume is outside of the management scope of docker. It’s a host volume, so it’s tied to the host. In the tight scope of our needs for doing Postgres, I think this is the option we should stick with. It just makes things explicit, and we don’t need to move our containers.
Anonymous volumes: (i.e. -v /dock/app/folder or VOLUME /dock/app/folder in dockerfile). This creates a randomly named folder somewhere in /var that is mounted into the container. If you don’t docker rm –v the container when you are done with it, this folder will get orphaned, and you’ll leak disk space. While you can use docker inspect to find the folder, there is no real tooling for working with the volume or managing it’s lifecycle. By themselves, these volumes aren’t really useful. They have some performance and reliability implications, but really they are more of a hole in the abstraction, than an operation tool in their own right.
Volumes-from: Using #2, we can create a container that has anonymous volumes, but give them a name/handle because they have a container that they are connected to. That container shouldn’t even be running, it should have been run and stopped or just by using the docker create command. Running the second container with —volumes-fom will have the storage from the first container be used as the persistent location for files from the running container. This idea is more compatible with docker cluster managers and portability, but it’s also awkward. You can’t create a data container with Docker Compose. You end up with IMPORTANT stopped containers lying around on your host (a lot of scripts that are out there for cleaning up orphans just delete all of your stopped containers…). For a long while, this has looked like the ‘docker way’ of managing persistent storage, but now it appears that things are changing…
Named volumes (i.e. -v myvolume:/dock/app/folder) in Docker 1.9, a cluster of new ‘docker volume’ commands showed up, and the ability to give an ‘anonymous volume’ a name showed up, and volume drivers are in there too. I wouldn’t dream of relying on this functionality yet, as it seems like things are rapidly changing, and theres a pile of bugs and feature requests on github on the subject, but this is a clear abstraction and vision for the future of volume management. In the future, there will be some sort of separate storage server, with it’s own management tools. You’ll be able to cluster and cache and backup volumes through that tool (probably there will be a number of competing solutions), and you will just run your container with it’s volumes specified by name and connect to the volume driver and it will be automagically managed for you. If you need to move containers around, the volume storage server will make sure your data moves too. We should absolutely use this. Next year or sometime.
In coming up with a solution, it’s good to have a checklist to work from. You don’t have to check all the boxes, but it’s useful to know which ones you’re taking a miss on. Anatomy of a Modern Production Stack · 80%
I’m reading Git From The Inside Out, which is an excellent tutorial on Git, from the viewpoint of it’s technology and data structures (rather than just a quick run through of the basic commands), so I thought it might be a good time to list out some other resources on using Git. Firstly the live tutorial by GitHub and Code School and the git book are worth looking into.
For graphical git clients on the Mac, the new hotness is GitUp, Atlassian gives out SourceTree for free, and GitBox or Tower are popular with the community. Working Copy is a git client for iOS so that you can read and work your code while on the go.
As a passionate, involved worker, there is too much that I want from an employer. How can any organization be excellent at all of the things that I need and allow me to really achieve? Look at the list of things you need as a software developer and that an employer needs to provide to be a place that will be fulfilling:
A work space that is collaborative but not distracting
Creative ideas and vision
A set of operable work practices
A motivating mission that keeps you inspired
A technical and business infrastructure
Supportive mentors that care about your growth
Opportunities for self-actualization and growth over an extended period of time
A community of humans that you can be welcomed in
Patience, care, and financial support of your health
It seems obvious that all of that is way too much to expect from a single organization, and yet with the structure of the full time job in the USA, we are only allowed to select one organization to provide the great majority of these needs.
If you want to run a good company and both hire and hold on to good employees, you need to have answers to all of these needs. Somewhere in the process of attracting and hiring new employees, these things need to be communicated, or you will have the same problem as every other business on your street and in your city: finding ‘qualified’ people.
A big component here has to be good managers. Software engineers have widely varying skill levels when it comes to simple task management and communication. Add cultural elements, and career evolution into the mix, and you’ll very rarely find a good programmer who is a good self-manager. If you further add any real organizational barriers, the job is impossible for even a good self-manager to do himself. Unfortunately, most technical managers are appointed from the outside on the basis of their ability to flog progress on tasks out of an engineering team. Wider goals of cultivating their staff are just not part of the mandate.
When engineering management is done right, you’re focusing on three big things. You’re directly supporting the people on your team; you’re managing execution and coordination across teams; and you’re stepping back to observe and evolve the broader organization and its processes as it grows … There are two things you should always be thinking about: People’s day-to-day and their year-to-year.
A manager needs to be a voice of courage and mission, since not everyone on the team can be brave and focused everyday.
Every committee or organization has at least one well-meaning person who is pushing to make things more average. … And, by amplifying the voice of the lizard brain, he gets under our skin and we back off, at least a little. We make the work a little more average and a little worse.
There is a failing of traditional engineering management. The best decision making for evolving our products usually occurs with the people doing the actual implementation. They have a commitment and insight and feel for their choices that a ‘boss’ cannot hope to replicate. At the same time, there are a number of duties that a team needs performed that are necessarily not the first focus of software engineers such as communicating clearly and redundantly with other groups, organizing the high-level roadmaps, being a coach/counselor/mentor, creating a framework for enlightened hiring, and more.
The typical authority-based manager is incentivized to ‘boss’ the decisions, despite being imperfectly informed, while leaving the nuts and bolts of facilitating the team and culture to his subordinates, since those tasks are beneath his dignity.
Our managers are not our parents. Their job isn’t to tell us to clean our room and eat our spinach. Our managers should be our coaches, our gurus, our fixers. Old school ‘adults in the room’ managers won’t build the teams that attract and hold great engineers.
The world of “management” is vertical. Its natural habitat comprises tall buildings in places like New York. Its mindset is also vertical. “Strategy gets set at the top,” as Gary Hamel often explains. “Power trickles down. Big leaders appoint little leaders. Individuals compete for promotion. Compensation correlates with rank. Tasks are assigned. Managers assess performance. Rules tightly circumscribe discretion.” The purpose of this vertical world is self-evident: to make money for the shareholders, including the top executives. Its communications are top-down. Its values are efficiency and predictability. The key to succeeding in this world is tight control. Its dynamic is conservative: to preserve the gains of the past. Its workforce is dispirited. It has a hard time with innovation. Its companies are being systemically disrupted. Its economy—the Traditional Economy—is in decline.
In many cases, it is easy to see that part of the compensation package for being a manager is the privilege of excercising power over your subordinates, limiting their access to information, and the gratification of being higher paid and having better work amenities than them. An organization that incentivises management in this way, and attracts managers who _want_ this kind of ‘payment’ is going to have a hard time getting value for what they pay their engineers.
“managers are being paid in non-pecuniary status benefits via underpaying their underlings, in a way that reduces total firm output, and there are coordination & principal/agent problems in getting management to agree not to be compensated in this way”.
Just because managers are often poor doesn’t mean they aren’t required, though. Information sharing, goal setting, and power inequalities are facts of business life, if not human life. Someone has to be responsible for negoatiating those waters. If you don’t name that person, you haven’t elminated the focus of power, you’ve just made it harder to figure out who holds that focus.
“Flat” organizations are often alluring lies that hide the real power structures. It doesn’t matter if Bob is an idiot who works 15 minutes per week; if the CEO will take Bob’s word over yours when it comes to your value to the company, then Bob is your boss. … why people hate management: we’ve all picked up that it’s serving its own interests rather than that of the employees or of the company. All of this said, “no management” tends either to produce an emergent and less accountable management/police force or it tends to mean that power is concentrated at the top.
Another essential role for managers in an engineering team is to optimally take advantage of the specific genius of the team members, while compensating for the ways in which those same employees are disruptive to an egalitarian team. Engineer types such as the Free Electron or the Honey Badger need specific accomidation. The team needs negotiation between Stables and Volitiles. Extroverts and socially adept team members provide a lot of obvious value, and so a manager needs to exist to elevate the introverts.
Dealing with all of these different types of people while continuously, conscientiously trying to achieve the best outcomes for them and the company is a real job, and it needs talented, dedicated people. Creating or finding these people is way beyond the scope of this post, but 10x developers and 10x teams need this kind of leadership, very badly.
When you’re making a critical decision, you have to understand how it’s going to be interpreted from all points of view. Not just your point of view and not just the person you’re talking to but the people who aren’t in the room, everybody else. In other words, you have to be able, when making critical decisions, to see the decision through the eyes of the company as a whole. You have to add up every employee’s view and then incorporate that into your own view. Otherwise your management decisions are going to have weird side effects and potentially dangerous consequences. It’s a hard thing to do because at the point when you are making a decision, you’re often under a great deal of pressure.
Ableton has designed their work around very small teams, focus on quality, focus on self-defined process on each little team. They tried bigger teams and Scrum, but found that it didn’t make the creativity flow. Ableton also has development salons and music salons. Developers are encouraged to train each other and share the technology. At the same time, they are encouraged to work in the business domain–in this case music–and share their creativity there as well. The developers care about the product and the mission and have control over the way things get done.
‘We have so many very smart, creative people here that capturing their ideas and also encouraging their creativity is super important and super valuable and I can’t imagine this not being component of a good development team.’
An empowered, connected culture is hard to keep going, especially as a company grows beyond it’s first twenty-something employees. Jason Evanish blogged recently about the changes that a company undergoes at that divide. These include losing the ability for a leader to have direct contact with all of the employees, that ‘what’s going on’ is no longer universal information, that employees become more political and career oriented, and that culture starts to become solid. He quotes Ben Horowitz: “Perhaps the CEO’s most important operational responsibility is designing and implementing the communication architecture for her company. The architecture might include the organizational design, meetings, processes, email, yammer and even one-on-one meetings with managers and employees. Absent a well-designed communication architecture, information and ideas will stagnate and your company will degenerate into a bad place to work.” (Ben Horowitz).
Oh no. Now I’ve done it. I’ve followed the web and found more from Horowitz:
Let me break it down for you. In good organizations, people can focus on their work and have confidence that if they get their work done, good things will happen for both the company and them personally. It is a true pleasure to work in an organization such as this. Every person can wake up knowing that the work they do will be efficient, effective and make a difference both for the organization and themselves. These things make their jobs both motivating and fulfilling.
In a poor organization, on the other hand, people spend much of their time fighting organizational boundaries, infighting and broken processes. They are not even clear on what their jobs are, so there is no way to know if they are getting the job done or not. In the miracle case that they work ridiculous hours and get the job done, they have no idea what it means for the company or their careers. To make it all much worse and rub salt in the wound, when they finally work up the courage to tell management how fucked up their situation is, management denies there is a problem, then defends the status quo, then ignores the problem.
Culture requires a firm statement of values from a leader who has thought about things first and made decisions and is continuously holding firm on those decisions. Reed Hastings at Netflix did that and documented the culture he wanted to maintain.
I frequently see CEOs who are clearly winging it. They lack a real agenda. They’re working from slides that were obviously put together an hour before or were recycled from the previous round of VC meetings. Workers notice these things, and if they see a leader who’s not fully prepared and who relies on charm, IQ, and improvisation, it affects how they perform, too. It’s a waste of time to articulate ideas about values and culture if you don’t model and reward behavior that aligns with those goals.
You have to be intentional about working career growth into your broader engineering planning and execution of projects coming down the road,” she says. The really difficult thing is that not very many people have a clear sense of what they want from their job, and even when they do, they aren’t forthcoming about it with their managers. Good leaders are experts at surfacing this kind of data and making it actionable. … To develop a long-term relationship with an engineer, you have to learn enough about them to provide a framework to think through their career growth together.
I’m terrible at understanding what my long-term motivations and goals are for working at an organization. I really need someone with a clear vision to tell me what the business wants from me, what success looks like, and to help me develop the tactics that will give me credit and recognition for my contributions.
Building a bureaucracy and elaborate rituals around measuring performance usually doesn’t improve it.
I agree with this sentiment, even though I’ve been at more companies where the idea of performance review was completely abdicated. I guess no reviews is better than bad reviews, but it really shouldn’t be structured…it should be organic and constant.
But for each of those “diamond in the rough” hires, there are 9 who are equally cheap but correctly priced (i.e. not very good). In the startup phase, these companies tend to assume that their early technical hires were “desperation hires” and throw them under the bus as soon as they can get “real” engineers, designers, and management. That social-climbing dynamic– constantly seeking “better” (read: more impressive on paper) people than what they have– lasts for years beyond the true startup phase.
High-level turnover and constant change of priorities and initiatives means that the lower-level people rarely get much done. They don’t have the runway. Ask a typical four-year veteran of such a company what he’s accomplished, and he’ll tell you all about the work that is no longer used, the project canceled three months before fruition because a new CTO arrived, and the miasma of unglamorous work (i.e. technical integration, maintenance necessary due to turnover) generated by this volatility that, while it might have been necessary to keeping the company afloat, doesn’t show macroscopic velocity. That doesn’t make the case for promotion or advancement. Eventually, the high-power people realize that they can’t get anything done because of all the executive instability, and they leave.
Seriously. If you want to learn how to sabotage personal growth for your engineers (and you’re probably doing it), then read the above article. If you want to be a better manager, there’s a million books on the subject, some by people linked to in this post. Even if creating your own system and philosophy of good management is too hard, there’s software available that can do most of that for you.
Good Tasks Worked On Collaboratively
What’s fun about going to work? Getting tasks done. Checking off items on the list is like a drug and it’s essential to having an enjoyable work-day. That’s the simple part. Beyond the basic benefit of having tasks and being allowed to complete them, there are dimensions of ‘helping my team out’, and ‘trusting that others will help me out’, as well as creating and tracking all of those tasks.
Tasks are their own reward, and if you have a healthy relationship between task assignment and completion, you don’t need to demotivate your people with false urgency (although, as discussed there, the completed tasks need to do something and have some value).
Tasks are an opportunity to be creative, and they have nothing to do with putting in your hours or getting done with your work day. Punching a clock is what happens when you have a helpless feeling that your work doesn’t finish or add value. This is the opposite of scoring some tasks.
It is amazing how many of the agile processes have been ‘managed’ into being a never-ending grind, when they are essentially designed to provide fast cycles of completion, value, and accomplish. Agile Process is about spinning a bunch of completable tasks! This is the reward you give the developers for them putting up with your changing business needs.
Good tasks get created through the process of communicating before, during, and after doing the work. Make sure you have done everything possible to allow people to communicate with zero friction while they are working. Slack, Skype, IRC, screen presentation software, are an essential start to this. Video conferencing is becoming easier to implement, and new services are springing up, some completely free. There is pairing software that lets you screen share with two cursors on the screen at the same time and plugins for Visual Studio that let you co-work throughout the whole IDE.
Sure, there are some built-in collaboration features in your bug tracker and source control system, but people are innovating really fast in this collaboration space, and if you’re just using the Out of the Box stuff, you’re behind. Enterprise social networks like Asana or Yammer are available. Tools like Peak monitor all of your cloud utilities for activity, and let the whole team know what you are working on without you having to fill out a single TPS report.
You can make your meetings much better by learning about Productive Meetings. Or if that is too much work, just use software that trains you while you use it. There is a lot of value in the meeting that is unharvested because people won’t create agendas or take minutes. Fix that.
A good meeting should produce a crop of actionable tasks, and you need to track those somewhere, right? Give your people complete freedom on how to track their tasks. Experimenting with different task tracking systems is a personal joy and investment in productivity, and it is constantly evolving. No unified Harrison Bergeron solution can possibly give you the benefits that you get from creative people trying to constantly improve. That said, there’s a lot of options. You can check your task list into source control with the code as a simple text document. You can buy everyone Franklin Planners. Screenful has tons of integrations and pretty graphs. Other tools will structure projects and calendars as well as tasks. It’s all good. Play with the tools, change them up, find things that work and stay out of your way and keep everyone focused. Have fun.
Agile process with backlog groomings and sprints and task boards is there to create the valuable tasks that engineers will get excited about finishing. It was not created, nor should it be used, to micromanage engineers to the point where they can never invent anything. If you need to control your engineers and prevent them from harming you with their creativity…you’ve hired the wrong people (or you are really broken)[or both].
Good practices, including communication and documentation, codestyle and unit tests, work flow and estimation, as well as design and architecture are all very important parts of getting the work done more easily and achieving quality results. As important as that, though, good practices provide an arena for engineers on a team to develop mastery. These are things that you can be incontrovertibly ‘good at’ and feel a sense of pride and motivation about, even when you have technical, political, or market hurdles that are dragging you down.
One excellent area to develop good practices is in remote work. With poor office environments being such a common trial, and the challenges involved in getting any group of more people to be consistently in the same place at the same time with any frequency, the ability to work remotely is potentially a huge benefit. Even if remote work is the exception, rather than the rule, creating the skills and habits needed to enable remote work can really elevate your development practice.
since we went remote, pairing has become really popular. No sharing body odour with your colleague, we just share our screens with a headset on. We learn from each other and challenge each other. We keep each other honest and out of rabbit holes. When things get tricky we grab another pair for a quick swarm. There is banter, it’s fun and there is a strong commitment to quality. We continually question our practices and listen to each others’ frustrations. “Are we really creating something that is really needed or just getting those stories across the board?”
Zach Holman talks a little bit about what asynchronous and remote work at GitHub is like. There are some very natural, to engineers, ways in which collaborating through your computer ease the overhead of doing things together. One thing I like in his post is the tantalizing suggestion that communicating in *code* and through *source control* can replace the need for whiteboarding and design meetings. Communicate in the medium that your results will appear in, yeah?
Whichever agile practice you actually follow, it is really worth learning the vocabulary and tools of lean and kanban. Very smart people have thought a lot about how to communicate and structure the tasks of software engineering to reduce the amount of work and the amount of wasted work that is performed. Lean and kanban can be an unending source of new insights on smoothing out your day to day process and improving quality.
Engineers don’t hate process. They hate process that can’t defend itself. … If you want to piss me off, if you want me to hugely discount your value, do this: when I ask you a clarifying question that affects how I will spend my time, my most valuable asset, don’t answer the question. This non-answer is the root cause of an engineer’s hatred of process. A tool that should help bring order to the universe is a blunt instrument that incites rage in the hands of the ignorant.
Kanban is more than a board with sticky notes on it, and moving cards across a board is completely orthogonal to the ideas of reducing waste and eliminating points of delay (James Shore and Arlo Belshee have a number of insights on this in their Single Piece Flow in Kanban talk). Engineering kanban is also designed to reduce multitasking and get things completed more quickly by giving your workers slack time.
Shorter term process, with real, constant delivery of business value is very useful in getting a group on the same page in terms of what is getting done, who is doing it, and why the current piece is being done first. This is important in a business environment where there’s a natural tendency of management to want to provide a general hand-wave of direction when requesting a project, and then to immediately demand an estimate. With insufficient information and pressure to commit to a timeframe which is inherently unknowable, it is likely that communication with the business will devolve into estimation games that serve to encapsulate the lies of poor estimates in a capsule of emotionality and politics that only serves to establish long-term distrust and disfunction.
So, the shorter term planning process of sprints or cycles or iterations serves to create a level of honesty and trust and communication. This cannot be left alone as the end goal, however. If the end of mature process in an organization is scrum, there will never be a place for discussion of strategy or a place for senior develops to do the research that truly justifies their skills and salary. Eternal scrum can be a demoralizing, micromanaging grind of small tasks that can eventually demoralize your teams and destroy your company.
Just don’t buy too deeply into the idea that by getting the responsibilities of your software right, that you will somehow reduce the impact that all of that business dysfunction has on you as a software developer. Part of the maturation process for a company is cleaning up its’ business processes in parallel to cleaning up its’ software processes.
Software engineering isn’t a healthy career. I don’t mean to say that it has to make you unhealthy, but rather that the format of the work isn’t inherently one that develops health. Sitting quietly, thinking and typing doesn’t do a lot for your physical health in the way manual labor can. Creating conditions for extreme mental focus can be wearing physically as well as psychologically. Creating an excellent culture around software engineering mean that you have to design health into your culture in ways that are innovative and sometimes risky.
One area of health improvement needs to be a focus on the length and nature of the work day. Lots of overtime and extended periods of crunch time end up being counterproductive and are poor for engineer health in some obvious ways. It takes courage to limit the amount of work time your team puts in, even though the evidence shows that putting in less than eight hour days improves results. Different people have different needs for work hours, and adults can supervise themselves.
The layout of your workplace is another factor in encouraging or destroying employee health. It is well known that a noisy workplace is detrimental to knowledge workers, and yet cubicle farms and open office places are the norm. I’m sure you work with some people who are introverted, since software engineering is a career that is made up of a large proportion of introverts. The panic of being exposed to lots of people with little privacy can tear up the psyche of an introvert in ways that are impossible to justify on the basis of the marginal cost savings involved in square footage.
One solution to the troubled office environment is remote work. If you have a noisy, crowded, non-private office…at least you can work from home. Stanford research has shown that remote workers are more productive and healthier. Companies like 37signals and Github have nailed down their place as market leaders in the context of aggressive remote work capabilities.
The mindset needed to get a large team focused on tasks and meeting timelines for complete features is very important for the success of a business. A focus on tasks and limited scope is also valuable to engineers as it provides a means to have constant success and feedback about work well done.
I want to point out, however, that getting those tasks done reliably and quickly is more than an assembly job. It requires creativity and flow. Having a culture that, like Github, celebrates that required creativity and nurtures it is very important in achieving results out of your teams. It is also, in the long term, essential for keeping that irreplaceable, expensive team together.
“I’ve learned that I’d rather work by myself than with subpar performers,”
Your company acts as a filter for the people who work there. Do you filter out the bad people and concentrate together a better, higher quality group focused on excellence? Or do you filter out the excellence?
If you’re careful to hire people who will put the company’s interests first, who understand and support the desire for a high-performance workplace, 97% of your employees will do the right thing. Most companies spend endless time and money writing and enforcing HR policies to deal with problems the other 3% might cause. Instead, we tried really hard to not hire those people, and we let them go if it turned out we’d made a hiring mistake.
This has been a (by no means comprehensive) survey of some gripes and opportunities in the area of company culture. Working on this stuff is hard, but if you’re not making a real effort to work in at least some of these areas, you shouldn’t gripe about the fact that you can’t find quality people to fill your empty seats. Quality people have jobs right now, and they don’t have any real motivation to come work for you if your culture shows a half-hearted, hand-waving interest in their well being.