It really is shocking how many marketing practices and how much of the sales mentality is stuck in the Glengarry Glen Ross era. Time for the lines between dev and, basically, the rest of the business to blur for good!
Never realized there were so many ways to go about creating space for deep work. I see and use the Bimodal strategy most often, but I'm interested in how Rhythmic might work. Personally that last one, Journalistic, just seems like setting yourself up to never get anything done.
Never realized there were so many ways to go about creating space for deep work. I see and use the Bimodal strategy most often, but I'm interested in how Rhythmic might work. Personally that last one, Journalistic, just seems like setting yourself up to never get anything done.
Faster load time, easier scalability, and the overall affordability that these two elements introduce are probably the strongest argument in favor of looking into static site generators.
Diffuse thinking is becoming harder and harder to come by because it's so easy to stay connected 24/7! I try to spend some downtime (walking, cleaning, shopping, etc.) every day without my phone to give my brain time to slip into this kind of thinking. Great research!
Increasing developer longevity is an especially interesting point. As it turns out, developers are actually humans who appreciate variety and want to take pride in their work!
Having worked in some departments with developers before, I agree with you! They take A LOT of pride in their work and don't want it mucked with by outsiders who don't understand the language or who have no REAL RESPECT for what they do.
I track my time, too, and my biggest complaint is how long it takes. I think it's a great idea for companies to show why time tracking matters so it doesn't feel so futile.
Some companies just want a panopticon. Many of them want to micro-manage, and have weird ideas that software development is a direct correlation between time and effort.
My current company it makes sense to try my best to the hour/half-hour, because we're consultants and that's how we bill our clients.
A past employer for me was the worst of both worlds because they had a consultant's mindset towards billable hours having been born of a law firm, but not the consultant's approach to billing software development work. We were classified purely as "overhead" and not allowed to "bill" our (internal) clients. Meanwhile, despite starting life as a law firm it was by that point mostly a call center, and call staff to lofty law firm partners look like babies that need a strict panopticon.
If in the US definitely a company fail to inform. Done properly developer salary supported by time records can help qualify some portion of the salary for the R&D tax credit. At least that's what they tell us where I slave (a $FORTUNE_500)
Where things fall apart for me is logging overhead time, like time spent waking up with the first cup of coffee while reading company emails or doing IT-ish tasks on my dev system. I have no idea how to account for those times that doesn't make a mockery of the "Other" time entry.
Ugh. I don't ever want to work for a company where my time tracking has to be so fine grained that I have to log bathroom breaks. Holy shit that sounds like a nightmare!
I actually worked for a company where they didn't allow me to have a bathroom break during working hours while I was remoting...such is life as a 53yo developer trying to make any kind of living in this industry.
In fact, I had to log X keystrokes and Y LOC every hour in order to be paid for that hour...talk about being a factory worker.
I hate to use the "you should be looking harder" trope, but every company I've worked at has had developers at or over 53, and not one of them had such onerous time tracking requirements.
One tracked time to attempt to get r&d tax credits on certain work. The other was an agency that tracked time in case of disputes with unruly clients (such as the time we had gone through 3 project managers and 2 CFOs while we worked with them, and they were desperate to recover money from their own bad mistakes). The rest didn't track time at all.
Usually its not that you specifically need to log your bathroom break, but rather that all your time you spent at work needs to be booked on _something_
Lol, I remember being in a billable environment and making so much shit up. Reading emails? Billed to project Y. Bathroom break? Billed to project X. Politely listening to my boss gab? Billed to project Z.
Now that I manage my own team I let them abuse the Other time entry. I only expect 70-80% billable anyways, which lines up with studies on productivity. Anybody expecting 100% productivity is an idiot and anybody reporting 100% productivity is a liar.
I'm fortunate to be in a place where our time-tracking is not expected to add up to 40 (or 80) hours a week. I log the work items I do, which sometimes is six hours and sometimes is one hour a day.
I make those a pretty broad category -- "email" "time waste" (that one's just for me). If the time tracker is simplistic and intuitive enough, then it doesn't have to be a headache.
At one previous employer I submitted a feature request for the time tracker that would have saved a lot of time - it was a button that would generate something that was basically "like last week but with some plausible looking random changes".
Now I think about it - should have been a cron job, maybe that was why it was rejected.
What level of granularity are you required to track? I track how much time a spend working on a particular feature, regardless of the type of work being done. When I take a break or start working on a different feature I make a note of how long I worked since I started. It takes less time than writing a commit comment, which I usually do right before I jot down how long I worked on it.
I think it's really important to highlight the fact that one deployment option isn't better than the others. Instead, it's relative to what resources you have and what outcome you want.
I definitely saw this issue a lot back in the agency world. The tip I like the most is to have independent thinking sessions before (and also after) coming together to brainstorm as a group.
