7 dicas para uma vida mais feliz

principle_4_8Olá! Como estão as coisas?

Neste post, quero compartilhar algumas dicas com você que deseja ter uma vida de mais satisfação e alegria. As dicas são do livro “The 4:8 Principle“, de Tommy Newberry.

O livro tem como tema chave o conselho bíblico dado pelo apóstolo Paulo em sua carta aos filipenses:

Finalmente, irmãos, tudo o que é verdadeiro, tudo o que é respeitável, tudo o que é justo, tudo o que é puro, tudo o que é amável, tudo o que é de boa fama, se alguma virtude há e se algum louvor existe, seja isso o que ocupe o vosso pensamento.” (Filipenses 4:8)

Vamos às dicas:

  1. Cuide dos “primeiros 15” – O que se faz nos primeiros minutos da manhã estabelece o tom emocional para o dia inteiro. Tente iniciar os 15 primeiros minutos do dia enfocando-se em coisas boas, que promovem alegria. Ouça uma música que você gosta, medite em versículos da Bíblia, faça uma oração, pense em motivos de agradecimento.
  2. Cuide dos “últimos 15” – De maneira semelhante, encerre o dia com alegria, dedicando os 15 minutos antes de dormir para pensar em coisas boas. O subconsciente  de uma pessoa está altamente propenso a ser influenciado pouco antes de uma pessoa adormecer. O que é impresso no subconsciente é algo que se consolida mais profundamente nas emoções e que depois se expressa nas circunstâncias (ver Pv 4:23).
  3. Pratique as “perguntas 4:8” – O autor chama de “pergunta 4:8” uma pergunta sobre a vida que extrai uma resposta positiva. Exemplos: a) quais são cinco coisas pelas quais sou grato agora mesmo? b) quais são cinco de minhas maiores realizações até o momento? c) quais são cinco das pessoas que mais me amam? Perguntas desse tipo são boas para serem usadas nos primeiros ou nos últimos 15.
  4. Enfoque-se nos relacionamentos certos – Ande com pessoas que possuem os mesmos valores que você, que te inspiram e te encorajam a ser uma pessoa melhor. “Não vos enganeis: as más conversações corrompem os bons costumes“. (I Co 15:33).
  5. Cuidado com a avalanche de informações negativas da mídia – os noticiários de televisão, em sua maior parte, nos lembram de tudo o que não está bem no mundo. Somos expostos a todo tipo de problema, e a quase nenhuma solução. Limite o tempo que você gasta assistindo a notícias e coisas do tipo. Use seu tempo para se desenvolver com coisas duradouras e de maior valor.
  6. Memorize versículos da Bíblia – A mente consciente só consegue se ater a um pensamento de cada vez, seja ele positivo ou negativo. A única maneira de se eliminar um pensamento negativo é substituindo-o por um pensamento positivo. As Escrituras estão repletas de promessas de Deus e são excelentes para se manter uma perspectiva otimista e sadia da vida. Além de memorizar, personalize versículos bíblicos e reafirme-os para si mesmo. Por exemplo: “Cristo veio para que eu, Joãozinho, possa ter vida e tê-la em abundância.” (João 10:10)
  7. Tenha um coração grato – A gratidão é uma arma poderosa contra emoções negativas. A Bíblia diz: “Deem graças em todas as circunstâncias, pois esta é a vontade de Deus para vocês em Cristo Jesus” (1Ts 4:18). Gratidão é uma convicção, uma prática e uma disciplina. Significa enfatizar o que temos presente e está funcionando em vez daquilo que nos “falta” ou não está dando certo. A gratidão pode ser experimentada em níveis cada vez mais altos. O salmista disse muito bem: “Bendize, ó minha alma, ao Senhor, e não te esqueças de nenhum de seus benefícios.” (Sl 103:2). Aprenda a valorizar e a ser grato pelas coisas simples da vida!

A qualidade e saúde das nossas emoções é determinada pela qualidade dos nossos pensamentos. Essa é uma boa notícia, pois significa que não precisamos ser vítimas dos nossos sentimentos e emoções. Aqueles que experimentam mais alegria não são necessariamente os que possuem mais motivos pelos quais se alegrar; são apenas pessoas que pensam de forma diferente. As dicas mencionadas neste post podem ajudar muito uma pessoa a aplicar o “filtro” de Filipenses 4:8 a seus pensamentos, e ter, como consequência, uma vida muito mais feliz.

Advertisements

Book review: Domain-driven Design

Last year I finished reading the excellent book Domain-driven Design, by Eric Evans; but it was not until now that I’ve managed to put aside some time to write about it.

In a time when we have lots of different kinds of cool tools and technologies, it can be easy for us developers to become entangled in those issues and forget to pay close attention to the core problem domain. The approach of Domain-driven Design (DDD) shifts the focus back to the domain, joining together developers, users and domain experts through the use of a common language, spoken and understood by everyone: the ubiquitous language. With the terms of this shared language, we can develop a model which will be used to drive design (hence the term “model-driven design“). The idea is for the code to faithfully reflect this model. This approach enables excellent communication among the stakeholders and empowers the design with the richness of the domain which in turn makes it possible for the system to evolve more easily as the users demand new features.

And that’s Domain-driven Design in a nutshell! Simple, isn’t it?

Yes, that is DDD. However, putting that into practice is a whole different thing. In the book, Eric Evans explains how to apply DDD, what are the some of the challenges and difficulties, how to express the model in code, supple design, patterns, large-scale structures, etc. I definitely recommend reading the book, especially  parts I, II and III.

Just one more comment to finish this post: I came to the conclusion that it is virtually impossible to apply DDD without continuous Refactoring. This happens because the ubiquitous language and the model are constantly evolving as developers and users gain new insights. Actually, coming up with a good model is a strenuous task and, therefore, things are likely to change often (especially at the beginning of the project) and the code needs to easily accomodate these changes. Since it’s unwise to do refactoring without automated tests, some flavor of Test-driven Development is highly desirable as well.

Book review: The mythical man-month

After nearly two years of procrastination, I finally finished reading Fred Brook’s classic “The mythical man-month: essays on software engineering”. It has lots of useful insights on software project management and development. Rather than making a summary, I’ll just go over the pivotal concept found in the book: conceptual integrity.

The author goes at great lengths in how to achieve conceptual integrity in our software products. From my understanding, he considers conceptual integrity as a user-centered view of the software system; and, therefore, it’s something deeply connected to ease of use. For the author, this is the most important thing to consider in system design. There are severe challenges that stem from large programming projects, where division of labor can make it harder to preserve conceptual integrity. And that’s why he suggests the role of the architect, who is the person responsible to envision the system as a whole and make sure the conceptual integrity will be preserved. As I mentioned, Brooks used this concept primarily to talk about the software product as perceived by its users. In my view, the idea of conceptual integrity is one also to be pursued and applied to the more inferior levels of the software system (e.g. software design, code). On a project using Agile practices, such as XP‘s collective code ownership and emergent design, good communication is crucial to achieving conceptual integrity in code.

The book is mandatory reading  for any developer or software development manager. The phrase “there is no silver bullet”, for example, which has become something of a cliché in our industry, comes from an author’s paper “No Silver Bullet – essence and accident” and it was included as a chapter in the book.

Nevertheless, I do consider some parts of the book to be dated (the book was first published in 1975!). If you have little time, in a first reading consider reading chapters 1, 2, 3, 4, 7, 10, 11, 13, 16 (No silver bullet), 17, 18 (this chapter is a nice summary of the whole book) and 19 (this is a review of the original publication after 20 years). After reading this book, you may also consider reading the author’s new publication “The design of design” (I myself haven’t read it yet, but have seen good comments about it).

As a side note, I liked seeing the author use some bible-inspired thoughts to make some of his points in a technical book. A few areas of knowledge (e.g.: management, oceanography, etc.) have already benefited somehow from the wisdom found in the Scriptures. We still have a whole lot to learn in our craft and I really think the Word of God can be a source of inspiration no matter the subject matter. I finish this post with a quote by Brook’s himself:

“We need a God-given humility to recognize our fallibility and limitations”.

Book review: Writing Effective Use Cases


“Writing Effective Use Cases”, by Alistair Cockburn, is an excellent reading  for those who want to learn the art of writing good behavioral specifications in the form of use cases. The book is fairly easy to read, it contains plenty of examples of use cases and also presents good tips and the pitfalls to avoid when writing a use case. In this post, I’ll summarize some of the things I learned from the book.

The whole point of the use cases technique is to describe interactions between actors in order to accomplish a goal, while protecting the stakeholders’ interests.  They are usually written in simple text form (they can be either more casual or more formal, depending on the needs and characteristics of the project) and can be used to describe the behavior of any “system”, be it a software or an enterprise or business process (this is the “scope” of the use case). They can also be written viewing the system either as a white-box (considering the inner workings) or as a black-box (considering the external interface).  The former is more used to describe business processes while the latter is more used to describe the functionality of a software system to be designed.

The author uses a set of graphical symbols to denote the scope (computer system, organization, component) and level of the use cases (summary, user-goal, subfunction). The idea of levels is an interesting one because it allows use cases to be treated as an ever-unfolding story – a piece of behavior can be a simple step in a use case or a use case of its own (to increase the level, ask “why”, and to decrease the level, ask “how”). Especially useful is the advice of writing a few summary use cases that connect all the other user-goal level use cases, thus providing overall context and a good starting point for whoever wants to quickly figure out the whole picture.

To make the most out of the writing process, the author recommends working breadth-first, from lower to higher precision. This way, it’s easier to manage the energy and not get quickly overwhelmed with lots of details of the extension conditions and extension handling sections.

It’s also emphasized that use cases are not all the requirements, they are only the behavioral requirements. There are other requirements, such as business rules, performance, protocols, UI, data formats, etc. However, use cases do act like a glue that connects all the other requirements. The author illustrates this through the “Hub-and-Spoke” model of requirements, which sees  use cases as the hub of a wheel with the other requirements being spokes that lead in different directions; and that’s why some processes have a strong focus on use cases.

The author provides several reminders and checklists for improving the quality of a use case (those are nicely summarized at the beginning and at the end of the book). Among those, I quote the following three questions to be asked regarding every use case:

  • To the sponsors and users:
    • “is this what you want?”
    • “will you be able to tell, upon delivery, whether you got this?”  (acceptance tests are great for addressing this one)
  • To the developers:
    • “can you implement this?”

In a nutshell, the book is full of useful recommendations and what is exposed can surely be applied in order to improve requirements elicitation in any project, whether using use cases, user stories or any other technique.

Book review: Managing Humans

I’ve finished reading Michael Lopp’s book “Managing Humans – Biting and humorous tales of a software engineering manager.”

The book is full of anecdotes describing the world of a software engineering manager. Despite the rather slangy style of writing (sometimes using bad language), the book encompasses several facets of management and is full of thoughts useful both for managers and for those who deal with managers (that is, all of us!).

It is divided into three parts: 1) The Management Quiver, 2) The Process is the Product and 3) Versions of You.

Next I transcribe some of my favorite quotes from the book along with my comments.

  • “Managers who don’t have a plan to regularly talk to everyone on their team are deluded”. Everyone likes their opinions to be heard and considered. When managers don’t talk and listen carefully to what their employees have to say, besides disheartening the team, the company is bound to lose great talents and ideas.
  • “The organization’s view of your manager is their view of you”. Therefore, it’s quite important for one to work out the relationship with their manager. Where does your manager want to get? What does he want to achieve? What is important for him? As an employee, you need to figure that all out and make sure that your manager is making progress, because if he succeeds you eventually will succeed. (Conversely, if a manager wants to be successful, he needs to consider these questions in regard to the members of his team.)
  • The author talks a lot about meetings and the different kinds of people that take part in those meetings. In meetings, there are two major sorts of characters that need to be identified: players and pawns. The former is directly interested in the result of the meeting, while the latter typically gives no contribution. Knowing how to identify and deal with these roles is important in order to make the most of a meeting.
  • In the last part of the book, the author described the several meeting creatures (another spectrum of sorts of people found in a meeting). Especially important is the synthesizer, which is the person who can gather all the sparse information thrown by people and turn it into clear-cut sentences understood by all. In my company, during the planning meetings of our sprints (we’re running Scrum), we usually refine the backlog along with all the team, scrutinizing each user story. In this process, several people make comments and we can spend quite some time discussing a single story. When the time to give the estimate comes, it’s extremely useful to have one person be the synthesizer, summing up what the story actually consists of.
  • Information conduit – “for each piece of information you see, you must correctly determine who on your team needs that piece of information to do their job”.  A manager selfish when it comes to information simply won’t be completely trusted by the team. Worse, as the author points out, “in the absence of information, people will create their own.” I also considered quite important the advice to give each piece of information we’re passing on a bit of our personal context. For example, how many times have you sent out an e-mail with a link to something interesting you read, but without adding anything to it, just the raw link? I’ve done it many times. Now I try to at least summarize what I am forwarding and preferably give some personal opinion.

Overall, I would say that the idea of using tales and humor to illustrate the ins and outs of management was a good one, but that could have been better explored. Nevertheless, the book has more illustrations and good advice for anyone interested in this topic (there’s also a humorous glossary of management at the end whose explanations are quite direct and helpful).

Book Review: My Job Went to India

my_job_went_to_indiaI´ve just finished reading “My Job Went to India”, by Chad Fowler. The book contains 52 tips on how to be a better professional on the field of software development. I highly recommend the book for every developer who cares about his job. It´s a perfect complement for the already classical “The Pragmatic Programmer”.

The author goes over a variety of topics on how to proactively manage  a career on software development. He uses several metaphors and examples taken from his experience on offshoring in India.

 The book is split into six parts, namely: 1 – Choosing your market, 2 – Investing in your product, 3 – Executing, 4 – Marketing, 5 – Maitaining your edge, 6 – If you can´t beat´em. I´ll talk a little about three of some of the great insights from the book.

1) Supply and Demand – “Exploit market imbalances”: The author applies the well-known Supply-and-demand phenomenon to our careers. The idea is that the higher the demand for programmers that know a specific technology (say Java) the lesser will be the average price paid to these programmers. On the other hand, the demand for other non-mainstream technologies, though small, usually generates higher paid jobs since there are few skilled people able to supply that demand. Exploring these technologies may increase the chances of one getting a more well-paid job.

2) Be both a Generalist and a Specialist: This issue has generated a lot of debates and we can find several articles and blogs discussing it. The book advises us to be both generalists and specialists. “Generalists are rare, and therefore, precious”, besides that, our skills should not be attached to any specific technology platform. Nevertheless, we should strive to be specialists in the tools we use on a daily basis. The author comments that specializing in something does not mean not knowing about other things!

3) Mentorship: We all know people that are more experienced than us in our field. The advice is to find a person among those people to be our mentor. A mentor is someone who we can trust and that will provide advice on real issues that appear on our careers. The other facet of mentorship is to be a mentor. The author points out that for us to find out if we really know something, we should try to teach it to someone else. The concept of learning through teaching is a key to better understand if one really knows about whatever he claims to know. By the way, maintaining a blog on some subject is a great way to do this!

There are many other awesome pieces of advice in the book  concerning time-management, self-marketing and remarkability.

After every tip, the author usually gives some practical “homework” for the reader to act on what was just read. A great way to move from passive to active reading.  The title of the book is quite misleading, since it´s not a book with a focus on offshoring (although the author uses his offshoring experience to illustrate some points).  The publisher recognized that and came up with a new edition for the book, which is now called “The Passionate Programmer: Creating a remarkable career in Software Development.” 

A great career in Software Development (and indeed in any field) does not happen by chance.  We need to be consciously putting effort to develop and improve our skills in order to be excellent in our craft.

“Do you see a man skilled in his work?
       He will serve before kings;
       he will not serve before obscure men.” (Proverbs 22:29)