Scrum defines very little: working in teration, Product Owner, regular checkups. Other than that, there's a lot of space that gives you freedom and choice how to perform the actual work. Eg. you are free to skip estimations altogether (this isn't a Scrum thing per se; good practise at best).
If you ask if scrum is good then I read it "if working in iterations with PO and regular checkups is good" and my answer is yes. But you can achieve the same with kanban or any agile workflow.
There is a lot of misconceptions about what is and what isn't scrum. Eg. the fact that all scrums I've seen come automatically with estimations is Cargo Cult to me. From my experience, problems with scrum don't really relate to scrum, but rather these Cargo Cults or "our scrum incarnation", which comes down to misunderastanding it.
Professional communication in IT is my thing and it's particularly important now, during the pandemic / social distancing / remote work turmoil. Here is one good article to start, it covers the communication topic top-down:
I've felt it from time to time. The books helped me: in the subject, I recommend "Happy" by Derren Brown and "Man's Search for Meaning" by Viktor Frankl. Anything related to stoicism can work as well.
Also, not sure if this counts - recently I've been having a feeling that I no more like programming. The reason: I have a different mindset than the vast majority of programmers I met. It feels like either I'm the only one who knows how to do it well, or I'm the only one who doesn't know that. This feeling I've not yet overcome. I will probably try to change the job OR look for a different project / team.
- acting like the ticket is done when it's pushed to code review (not taking review, QA, release, etc. into account). This implies a lot of miscommunication, think daily: "I'll finish this ticket today" -> ticket released 5 days later
- in case of communication, assuming that doing anything (usually one message in a convenient way - face to face, email, Slack) is the best they can do. No. In communication, you're actually responsible for the outcome.
- focusing on technical knowledge rather than soft skills (not to mention good sleep, diet and exercise)
- doing convenient job; not asking "What's important NOW?"
There _are_ an infinite number of _things_, but which ones are important it's up to you.
I will be advocating GTD. It doesn't only give you the framework. Once you're done with the basics, it also allows you to make clearer decisions. A nice quote (self-translated, I wasn't reading in English): When the boat sinks, you don’t think about its course.
"Essentialism" is another classic in the subject, more disciplined in rejecting unnecessary stuff, complementary to GTD in terms of your concerns.
* not forget small tasks that if piled up, eventually become too big or annoying to tackle (daily budget update, email zero-inbox, browser bookmarks cleanup). I group such repeating tasks in daily routines (morning routine, evening routine) or periodical reviews (weekly, monthly etc.)
* keep up the habits (flossing, weighing myself)
* keep up with events rare enough to forget some pieces of it (weedings - tie a tie, give the shirt to the laundry)
Similarly, in software development. I've realized recently that things get less cluttered if you have a process (a checklist, basically) with steps to cover in particular activities.
Examples:
* work shutdown routine (put a work log to Jira, reply all remaining emails, git push everything).
* Definition of Done (DoD): code delivered, tests written, docs updated, etc. That is useful if you (or your team) want up-to-date README but keep forgetting to update it.
But honestly, first 3 bullets are the most important ones; if done, I'm super concentrated the whole day (strangely enough, these 3 are basic stuff, you probably already know that from your mama).
1. "The Power of Habit" by Charles Duhigg. Gave me a better perspective on how to tackle my bad habits like endless watching YouTube after work, drinking too much coffee etc.
2. "The Power of Your Subconscious Mind" by Joseph Murphy. Sold me on the idea of positive thinking, but generally I found the book crappy.
3. "To Kill a Mockingbird" by Harper Lee. The only nover on the list. Definitely a good read.
4. "The Pragmatic Programmer". I fell in love with the idea of "the network" of views and controllers.
5. "The Software Craftsman" by Sandro Mancuso. Great one. Made me recosinder a few (quite a few!) things in my workflow and project.
6. "Deep Work" by Cal Newport. Amazing one. Can't wait for Monday to implement some at work. I even ordered 3 more copies for my team.
It's a software built on top of GTD methodology and I love its way of managing TODO lists.
First of all, the tasks are grouped by the projects, so you can dive deep when working on one the projects.
You can mark some tasks as "Next actions". All the next actions across all the projects will show in a"Priority" view, it's kind of a "mission control".
GTD advises you not to assign a due date for tasks unless it's essentially required (like in an appointment) and that works perfectly for me.
Another important piece of GTD is a weekly review when you plan what to do in an upcoming week. So whenever I'm in a mood to do something, I check what's left for this week.
If you ask if scrum is good then I read it "if working in iterations with PO and regular checkups is good" and my answer is yes. But you can achieve the same with kanban or any agile workflow.
There is a lot of misconceptions about what is and what isn't scrum. Eg. the fact that all scrums I've seen come automatically with estimations is Cargo Cult to me. From my experience, problems with scrum don't really relate to scrum, but rather these Cargo Cults or "our scrum incarnation", which comes down to misunderastanding it.