Take a ticket and deploy a solution to production. Such a rule takes peoples' heads out of the clouds and connects them with reality. Time and again, I perceive programming as a humbling experience.
Take a ticket and deploy a solution to production. Such a rule takes peoples' heads out of the clouds and connects them with reality. Time and again, I perceive programming as a humbling experience.
I actually don't think half a day is nearly enough. BUT I also don't think that this needs to happen every week. Sometimes, there are periods of exploration and discovery - whether it be with new technology, new approaches within the company, or coming up with some more grand long-term vision to align the tech org towards.
However, when you're out of discovery mode, you need to be in the weeds writing prolific code, feeling the impact (good or bad) of your decisions and course correcting as you go. Moreover, you need to see how other people are feeling about your decisions. At the end of the day, you're working in service of them, helping a team, teams, or the overall tech org to be successful, which in turn will (hopefully) help make the business successful. Often times when I hear disparaging stories about architects, they aren't fulfilling that tenet - either because they don't have the skill to do so or they believe everyone else just needs to keep up with their brilliance.
I've been in too many situations where once the "architecture" was done, the project was to be tossed to some engineers while I work full time on something else. Unless you have some awesome leads that are in lock step with the architect, then that is a recipe for disaster.
The last thing I'll say is that everyone writing code is an architect. You're inevitably making decisions about the way things will be built, no matter how small. Virtually all software has an architecture - but too often it's incidental architecture rather than intentional architecture. Make conscious decisions about your code, reflect on those decisions, and keep an open mind - whether you're just starting out or have decades of experience.
This is a key point, but People might say "software is eating the world", but many organizations are not yet at this point. You can find modern healthcare or pharma organizations which are doing real engineering, but this is still the exception in many places.
What you find is organizations which can still survive on old technology and the processes which got them there. At some point modernization will also have meant outsourcing tech to the lowest bidder. You have an organization which is unfit for engineering in the current state and the architects are more familiar with managing this process work than doing what folks here would consider real engineering.
These organizations are ripe for modernization. They have aging tech and tenured teams which can only make very incremental improvements. As market conditions change, leadership may decide that they really need to make changes and these people will be cast aside. It's a somewhat double-edge sword because the old folks do have value in that they understand all of the details of their business processes which are apparent to even a really good engineering and product team replacing them.
The problems they want to solve require an engineering culture. There are no ways around that.
Like many hospitals, they've been hit hard by COVID-19. They recently announced golden handshakes for people close to retiring. It's painful for people now, but hopefully someone will see it as an opportunity to change the culture.
Even an out of touch manager can contribute to and/or observe the state of the code base while pairing with someone who works on it full time.
Truth. At every job I start, I manage to say, "Wow, I am way behind these guys on what I know." That's not a bad thing because it's pushed me to grow.
I have worked all my life in organizations producing software, never once was this true: there was always some level in the organization were people stopped all programming tasks (with all the bad side effects of that, that the head does not really understand the capabilities of the organization, what is feasible and what is not...).
I agree with you, I just have not had the luck to see it.
You probably mean on average, and yeah, I agree. But the literal reading of programming half a day per week feels horrible.