Não sei se todos os detalhes foram factualmente assim, e não me importa. Às vezes como as coisas sobrevivem na nossa memória é tudo o que importa.
Guilherme Solari, “Eu menti para o meu pai sobre o cometa Halley“.
Never stop writing code
No matter how your role evolves, try to never stop coding (or if you cannot code, get involved in code reviews). You don’t necessarily need to be writing code that is on the critical path of your team (in fact, you probably shouldn’t) and you don’t have to be coding quarter after quarter, but you should try to do some coding on a regular basis.
Work life balance
Much has been written about finding work life balance. My 2 cents are simple. You do not reach balance by reducing work. You reach balance by finding a passion that draws you out of work. Of course, family comes first on this ladder, but we often need some other passion. In my case, I had the most wonderful experience writing a book about coffee. I did not plan it as a worklife balance treatment, I just realized it in hindsight. With the exception of spending time with my kids, I found that the evenings spent researching and writing about coffee (let alone the exotic trips I had to take as part of this learning) gave me hours of respite without thinking about work.
01. Faça algo analógico.
02. Mantenha-se saudável.
03. Abrace o desconforto.
04. Aprenda uma nova linguagem de programação.
06. Aprenda mais matemática.
07. Foque em segurança.
08. Faça backup dos seus dados.
09. Aprenda mais teoria.
10. Envolva-se com artes e humanidades.
11. Aprenda um novo software.
12. Termine um projeto pessoal.
Parkinson’s law of triviality, also known as bikeshedding, bike-shed effect, or the bicycle-shed example, is C. Northcote Parkinson’s 1957 argument that organisations give disproportionate weight to trivial issues. Parkinson observed and illustrated that a committee whose job was to approve plans for a nuclear power plant spent the majority of its time with pointless discussions on relatively trivial and unimportant but easy-to-grasp issues, such as what materials to use for the staff bike-shed, while neglecting the less-trivial proposed design of the nuclear power plant itself, which is far more important but also a far more difficult and complex task to criticise constructively.
The law has been applied to software development and other activities, and the term “bikeshedding” was coined as a metaphor to illuminate Parkinson’s Law of Triviality and was popularised in the Berkeley Software Distribution community by Poul-Henning Kamp and has spread from there to the software industry at large.
“Em qualquer disputa a intensidade do sentimento é inversamente proporcional ao valor das questões em jogo.”
TL;DR key recommendations:
– Once a project is completed, the team must ensure that the “What” and “Why” of each software item are properly documented.
– In the cases of parallel development of inter-dependent software modules set up a negotiation table to solve conflict between the development teams.
– Make sure that the development team is aware of the CMMI-ACQ or ISO12207 processes for negotiating with third parties.
– Make sure that testers are involved when negotiating with a third party for a potentially vulnerable software component. ￼
– Plan organization-wide process reviews to detect isolated processes and to promote information flows between processes.
– Planned special budget items to support long lasting corrections or corrections that are likely to benefit many modules. ￼
– Projects with strict deadlines are risky, and should be carefully monitored to avoid last minute unplanned activities.
– Team members should maintain a careful balance between the flows of information within formal development processes and informal human interactions.
– Team members should make sure that knowledge is appropriately distributed amongst them. For example, pair programming is a practice which can promote knowledge sharing.
– Any intrusion into the team dynamics by outsiders should be done very carefully.
I had to write bad code because sales and management usually dictate the timeline of the project.
As an example: sales promises new customer feature X in one month and we will lose money unless it’s implemented.
My choice is to either: 1) Complete it the right way in double the time or 2) use hacks and cut corners to get it done on time. Since non-technical people just see the output and not what’s going on underneath, they often times don’t see the difference and when they explain to the boss that they might lose money, it’s almost always option #2.
Being kind isn’t the same as being nice. It isn’t about superficial praise. It doesn’t mean dulling your opinions. And it shouldn’t diminish the passion with which you present them.
Being kind is fundamentally about taking responsibility for your impact on the people around you. It requires you be mindful of their feelings and considerate of the way your presence affects them.
1. Shut off alerts on your phone.
2. Get organized.
3 .Add estimated times to your to-do list.
4. Implement the 2-minute rule.
5. Make bad habits harder.
6. Work in bursts; take your breaks outside.
7. Designate yourself morale officer.
8. Upgrade your personal presentation.
9. Focus on your long-term goals.