Fedora 26 has been release about a month and a half ago. But I didn’t have the time to update my laptop until today. There was also nothing particularly exciting for me in this release, so there was no rush.
Here’s what I had to do today to update my laptop from Fedora 25 to Fedora 26:
# Let's get into root to save a few keystrokes
sudo su -
# Install all updates for Fedora 25
# Install dnf system upgrade plugin
dnf install dnf-plugin-system-upgrade
# Download upgrade packages for Fedora 26
dnf system-upgrade download --refresh --releasever=26
# Reboot and install Fedora 26
dnf system-upgrade reboot
If you need more help, have a look at DNF system upgrade wiki page.
The whole process took less an hour, but your mileage may vary. For me, the download itself was the slowest part. I had to pull down about 2.5 GBytes worth of packages, and given my office connection, it took about 35-40 minutes.
The installation itself took about 10-15 minutes, for which, I think, the solid-state disk (SSD) helped a lot.
One more reboot later, everything was up and running. Of all the changes pushed into this version, I think, the upgrade to PHP 7.1 is the one that affects me the most.
Joel Spolsky wrote “Fire and Motion” blog post back in 2002, but it is as relevant today as it was 15 years ago. It’s a good read on the subject of both personal and organizational productivity.
What drives me crazy is that ever since my first job I’ve realized that as a developer, I usually average about two or three hours a day of productive coding. When I had a summer internship at Microsoft, a fellow intern told me he was actually only going into work from 12 to 5 every day. Five hours, minus lunch, and his team loved him because he still managed to get a lot more done than average. I’ve found the same thing to be true. I feel a little bit guilty when I see how hard everybody else seems to be working, and I get about two or three quality hours in a day, and still I’ve always been one of the most productive members of the team. That’s probably why when Peopleware and XP insist on eliminating overtime and working strictly 40 hour weeks, they do so secure in the knowledge that this won’t reduce a team’s output.
As some of you already know, I’ve spent most of this week in London, UK. My first and only time in London was back in 2009, when I went there for a PHP conference (see this post, and this post).
This trip was very different. I stayed longer than the last time. I was mostly for business. I had much less time to explore the city as a tourist. So I thought I’d write it up, in case I case I need to remember some of it later.
Continue reading “London Trip”
“The Engineer/Manager Pendulum” is a great article about a career shift from engineering to management. Anybody who’s in engineering now and plans or even just wants to become a manager should read this. Anybody responsible for “promoting” engineers to managers must read this too.
Timofey Nevolin wrote an excellent article “Eight Rules for Effective Software Production” over at Toptal.com. The whole thing is well worth a read, but here are the 8 rules to get you started:
- Understand the IT Mentality
- Do Not Mix Software Production and Development Methodologies
- Use Persistent Storage as an Extension to Human Memory
- Stop Wasting Time on Formal Time Estimation
- Understand the Cost of Switching Tasks and Juggling Priorities
- Use Architecture Reviews as a Way to Improve System Design
- Value Team Players
- Focus on Teamwork Organization
All of these are good and true, but if I had to pick one, I’d say that rule 4 is my personal favorite. Sometimes I feel like I’ve spent a good quarter of my life in meetings, discussions, and other estimation sessions. And looking back at all of them, I have to honestly say that they all of them were a waste of time. The only useful part of an estimation session is a high-level project plan, but that can be achieved with a project planning session – much narrower goal, much more measurable, and much easier to achieve.
Jason Fried has an excellent write-up on the pros and cons of using group chat for the team communications, and some of the ways to make it better. We use HipChat in the company and while it’s vital to our operations and I can’t even begin to think how we could do what we do without it, it does have some negative side effects – exactly as James describes them.
The most valuable advice out of that long article is this one (I’ve heard it before a few times, but it’s worth repeating):
Think about it like sleep. If someone was interrupted every 15 minutes while they were trying to sleep, you wouldn’t think they’d be getting a good night’s sleep. So how can getting interrupted all day long lead to a good day’s work?
Sara Rosso shares some thoughts on what to document and share, after publishing over a 1,000,000 words while working at Automattic. Here’s the gist of it:
- If you’re the go-to person for something in your company, consider how much of it is just gatekeeper information you could document properly to help someone else learn/grow from or work on independently.
- Separate out processes and historical background from your strategic expertise. Processes and backstory are not really ‘what you know.’ It’s much better to be a person someone asks ‘why’ or ‘when’ to do something vs. the logistics of a ‘how.’ How can and should be documented for others to build off of regardless of your involvement. This should free you up to be more involved in the why, the new, and the next of your work.
- If you’re repeating yourself in private chats or (gasp!) email on a specific topic, document it. That’s also what drove me to create this blog – being able to answer someone’s question with an answer you’ve already carefully crafted for someone else is a great feeling (and a great use of your time)!
- Will someone want to know why you decided or executed something a specific way later? Share as much background as possible so colleagues are brought up to speed immediately. Share the setup & thought process you went through, where to find more information, and even the facts, ideas, or information you considered but deemed outside of scope for the particular project. My goal is to hopefully never have someone ask “where did this come from?” or “what’s your source?” or “did you consider this?” (when I had) and instead focus on enriching the discussion or challenging my ideas vs. asking me for information I should have provided in the original post.
- Gather the best, most complete, or authoritative things you’ve authored and submit them as potential onboarding materials for new team members. Challenge them to ask questions and to find something you need to document.
- If important progress is made, be sure to update your documentation, or retire in favor of something newer or more complete. We do this by linking from old posts to new ones, and all it takes is a quick comment and a link on an old post.
Quora thread on “What are some things you wish you knew when you started programming?” is a goldmine of wisdom. Irrelevant of how experienced you – whether you’ve been programming for decades or just thinking about a new career path, which programming languages and technology stacks you use, whether you’ve completed format education or taught yourself everything you know, I’m sure you’ll find valuable lessons and food for thought in there.