Posts Tagged ‘Livros’

Mais 10 livros recomendados para desenvolvedores

Monday, March 3rd, 2014

Lá atrás em 2008 escrevi um post sobre 10 livros recomendados para desenvolvedores. Na época o post foi bastante popular e eu sempre pensei em escrever uma continuação, que acabei nunca fazendo.

Enfim, a hora chegou e aqui vai mais uma lista de outros 10 livros recomendados para desenvolvedores! Mas antes disso, alguns detalhes sobre como cheguei nessa lista:

Por que apenas 10 livros e não 20 ou 30? Não sei dizer – o primeiro post foi assim então vou continuar. :) O bom é que isso me deixa uma quantidade de livros mais do que suficiente para no futuro escrever vários posts!

Por que essa lista tem livros sobre “processos” como Kanban ou Lean? Não era para ser livros para desenvolvedores? Não tenho pretensão de escrever aqui uma lista definitiva e restrita a apenas um tópico, mas sim listar alguns livros que pessoalmente acho importantes para desenvolvedores de software e que me marcaram de alguma forma. Nosso trabalho não é só programar direito mas também saber se organizar (ou organizar um time) para que se entregue mais software, com mais qualidade e em tempo recorde, portanto acho esses tópicos super importantes.

Por que um livro sobre JavaScript e nenhum sobre Ruby, Python, Java ou qualquer outra? Tem alguma preferência de linguagens rolando aí? Não tem preferência não. O “Good Parts” é sensacional porquê me fez entender e respeitar JavaScript de um jeito completamente diferente. Não acredita? Leia o livro então! Acha que é perda de tempo? Eu acho que não, JavaScript hoje em dia é uma das linguagens mais populares e é indispensável conhecê-la bem para fazer desde um simples website como este blog até gigantes como Yahoo e Facebook.

Por que todos os livros são em inglês? 99% de toda a literatura relevante de tecnologia é em inglês e em muitos casos não há tradução disponível, portanto se você ainda não está craque, pule esta lista e vá urgentemente aprender inglês antes de mais nada! De todas as linguagens (de programação ou não) que você pode pensar em aprender, essa é provavelmente a mais importante.

Clean Code: A Handbook of Agile Software Craftsmanship Clean Code: A Handbook of Agile Software Craftsmanship
Robert C. Martin
Test Driven Development: By Example Test Driven Development: By Example
Kent Beck
Growing Object-Oriented Software, Guided by Tests Growing Object-Oriented Software, Guided by Tests
Steve Freeman e Nat Pryce
Code Complete: A Practical Handbook of Software Construction Code Complete: A Practical Handbook of Software Construction
Steve McConnell
Working Effectively with Legacy Code Working Effectively with Legacy Code
Michael Feathers
JavaScript: The Good Parts JavaScript: The Good Parts
Douglas Crockford
Kanban: Successful Evolutionary Change for Your Technology Business Kanban: Successful Evolutionary Change for Your Technology Business
David J. Anderson
Lean Software Development: An Agile Toolkit Lean Software Development: An Agile Toolkit
Mary Poppendieck e Tom Poppendieck
The Lean Startup: How Today The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
Eric Ries
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
Jez Humble e David Farley

Como anda o seu inglês?

Tuesday, October 5th, 2010

Há não muito tempo uma pessoa me procurou no IM para conversar sobre sua carreira. Ela me disse que no momento estava fazendo um curso de Java e me perguntou o que exatamente ela precisava para trabalhar numa empresa como o Yahoo!. Conversamos sobre algumas coisas até que perguntei sobre seu inglês. Para minha surpresa, ela disse que o curso de inglês iria ter que esperar um pouco porque naquele momento ela estava priorizando o curso de Java…

Se você está numa situação parecida, faça o seguinte: pare tudo que você está fazendo e vá aprender inglês. Sério, no nosso mercado é muito, mas muito mais importante do que você pode imaginar.

Em primeiro lugar, alguns dos melhores livros existentes só estão disponíveis em inglês. Poucos títulos são traduzidos e quando são levam alguns meses (ou anos) para tal, isso sem contar que as traduções muitas vezes são ruins. Por exemplo, o Domain-Driven Design do Eric Evans levou aproximadamente 5 anos para ser traduzido, o Patterns of Enterprise Application Architecture do Martin Fowler levou 4 anos, e por aí vai. Hoje em dia o tempo é menor que isso, mas mesmo assim é muito tempo. Ou seja, você não só vai ficar alguns meses (ou anos) para trás como também corre o risco de não ter acesso a uma boa parte do conteúdo mais relevante disponível.

Em segundo lugar, os grandes players de TI publicam seus blogs em inglês – assim como vários dos desenvolvedores mais influentes no mercado. De forma alguma estou desmerecendo os blogs em português (como esse aqui), mas grandes nomes como Robert Martin, Alistair Cockburn, Kent Beck – e mais algumas dezenas que eu poderia citar – escrevem em inglês. Isso sem contar as dúzias de blogs como o TechCrunch, Mashable, High Scalability ou até mesmo o xkcd. Se você não entende inglês você não poderá aproveitar todo esse conteúdo.

Em terceiro lugar, a maioria dos projetos Open Source relevantes são em inglês. Por exemplo, você está acompanhando o desenvolvimento do Node.js? Você já estudou Clojure? E o Rails 3? Linux? Python? Projetos da Apache Foundation? Se você já brincou com alguma dessas coisas (ou todas) certamente foi porque você sabe inglês. E você pode não somente usar essas coisas para desenvolver como também estudar os códigos para entender como funcionam ou contribuir com os projetos. Enfim, um mundo gigantesco de oportunidades.

Eu poderia dar mais um monte de motivos – como dizer que a maioria dos lugares mais relevantes que todo mundo gostaria de trabalhar vão exigir que você saiba inglês – mas acho que só isso já é mais do que suficiente. Inglês é uma das coisas mais essenciais para profissionais de desenvolvimento de software e você não pode ignorar isso. Corra atrás e aprenda inglês “pra ontem”, essa é sua prioridade número um!

[PythOnCampus-RJ] Eu fui!

Monday, May 11th, 2009

Adorei participar do PythOnCampus nesse último sábado e conhecer várias pessoas muito legais da comunidade Python carioca (que não vou citar para não correr o risco de esquecer alguém)! Vejam as fotos no blog da comunidade PythOnRio.

Minha palestra sobre Testes e Qualidade de software em Python foi bem divertida! Quando percebí que a galera estava bem interessada eu deliberadamente estourei totalmente o tempo e ficamos quase duas horas falando sobre conceitos de testes, TDD e outras práticas de XP, doctest, unittest, pMock, Pyccuracy e por aí vai… Mais do que teoria, vimos bastante código Python!

Para quem não conseguiu anotar, a bibliografia que recomendei no final foi a seguinte:

Nas próximas semanas o PythOnCampus será repetido em outras faculdades pelo Rio de Janeiro. Acompanhem o site da comunidade PythOnRio para ficarem por dentro das datas e dos detalhes.

Livro: Tornando-se um excelente Product Owner

Wednesday, January 7th, 2009

Como já disse em outras ocasiões, o papel do Product Owner é um dos menos abordados em literaturas sobre Scrum – e o papel dele é tão fundamental para o sucesso de um time que é difícil de entender o porque.

Inspirado no livro Scrum and XP from the Trenches do Henrik Kniberg, Robert Galen está escrevendo um novo livro entitulado Becoming a Great Scrum Product Owner, disponível para download em PDF no seu site. O livro ainda é um draft e sua cópia/impressão/distribuição ainda não são permitidos, porém pelo pouco que já li estou percebendo que é um excelente material e que deve preencher um espaço muito importante na literatura de Scrum. E o mais legal é que claramente várias das coisas que estão escritas são fruto da experiência prática do autor e não apenas um monte de teorias.

Recomendo muito muito fortemente a leitura, especialmente se você for um P.O., quiser ter um time de sucesso e quiser ser um profissional de sucesso!

Livro promissor sobre mock objects

Wednesday, July 16th, 2008

Steve Freeman e Nat Pryce do JMock, um dos meus projetos favoritos, estão escrevendo um livro entitulado “Growing Object-Oriented Software, Guided by Tests”. O assunto é muito bom e conhecendo os caras e os materiais que eles já publicaram (especialmente o artigo que fala sobre a experiência deles evoluindo uma DSL, baseando-se no desenvolvimento do JMock – “Evolving an Embedded Domain-Specific Language in Java”), acho que o livro promete.

O primeiro capítulo já está disponível no blog do JMock e chama-se “What’s the point of Test-Driven Development?”. A leitura é obrigatória e já dá uma pista do que está por vir.

Portfólio intelectual

Saturday, April 12th, 2008

A discussão sobre livros e carreira foi acesa novamente, especialmente depois que escreví um post com indicações de alguns livros importantes para desenvolvedores. Recebí uma meia dúzia de e-mails perguntando sobre outros tipos de coisas que podem ser feitas para alavancar a carreira e até mesmo perguntando se existe algum remédio para ficar acordado e poder estudar mais :)

Não tem muito segredo, basta você encarar sua vida profissional da forma apropriada. Existem várias formas de fazer isso, e uma delas é pensar que você tem que manter o seu portfólio intelectual. No livro The Pragmatic Programmer, Dave Thomas e Andy Hunt apresentam esse conceito interessante que tenho usado há algum tempo:

Your Knowledge Portfolio

Your knowledge and experience are your most important professional assets. Unfortunately, they’re expiring assets. An expiring asset is something whose value diminishes over time. Examples include a warehouse full of bananas and a ticket to a ball game. Your knowledge becomes out of date as new techniques, languages, and environments are developed. Changing market forces may render your experience obsolete or irrelevant. Given the speed at which Web-years fly by, this can happen pretty quickly.

As the value of your knowledge declines, so does your value to your company or client. We want to prevent this from ever happening.

We like to think of all the facts programmers know about computing, the application domains they work in, and all their experience as their Knowledge Portfolios. Managing a knowledge portfolio is very similar to managing a financial portfolio:

  • 1. Serious investors invest regularly—as a habit.
  • 2. Diversification is the key to long-term success.
  • 3. Smart investors balance their portfolios between conservative and high-risk, high-reward investments.
  • 4. Investors try to buy low and sell high for maximum return.
  • 5. Portfolios should be reviewed and rebalanced periodically.

To be successful in your career, you must manage your knowledge portfolio using these same guidelines.

Building Your Portfolio

  • Invest regularly. Just as in financial investing, you must invest in your knowledge portfolio regularly. Even if it’s just a small amount, the habit itself is as important as the sums. A few sample goals are listed in the next section.
  • Diversify. The more different things you know, the more valuable you are. As a baseline, you need to know the ins and outs of the particular technology you are working with currently. But don’t stop there. The face of computing changes rapidly—hot technology today may well be close to useless (or at least not in demand) tomorrow. The more technologies you are comfortable with, the better you will be able to adjust to change.
  • Manage risk. Technology exists along a spectrum from risky, potentially high-reward to low-risk, low-reward standards. It’s not a good idea to invest all of your money in high-risk stocks that might collapse suddenly, nor should you invest all of it conservatively and miss out on possible opportunities. Don’t put all your technical eggs in one basket.
  • Buy low, sell high. Learning an emerging technology before it becomes popular can be just as hard as finding an undervalued stock, but the payoff can be just as rewarding. Learning Java when it first came out may have been risky, but it paid off handsomely for the early adopters who are now at the top of that field.
  • Review and rebalance. This is a very dynamic industry. That hot technology you started investigating last month might be stone cold by now. Maybe you need to brush up on that database technology that you haven’t used in a while. Or perhaps you could be better positioned for that new job opening if you tried out that other language….

Of all these guidelines, the most important one is the simplest to do:

Tip: Invest Regularly in Your Knowledge Portfolio

Goals

Now that you have some guidelines on what and when to add to your knowledge portfolio, what’s the best way to go about acquiring intellectual capital with which to fund your portfolio? Here are a few suggestions.

  • Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut. Additionally, learning many languages is far easier now, thanks to the wealth of freely available software on the Internet.
  • Read a technical book each quarter. Bookstores are full of technical books on interesting topics related to your current project. Once you’re in the habit, read a book a month. After you’ve mastered the technologies you’re currently using, branch out and study some that don’t relate to your project.
  • Read nontechnical books, too. It is important to remember that computers are used by people—people whose needs you are trying to satisfy. Don’t forget the human side of the equation.
  • Take classes. Look for interesting courses at your local community college or university, or perhaps at the next trade show that comes to town.
  • Participate in local user groups. Don’t just go and listen, but actively participate. Isolation can be deadly to your career; find out what people are working on outside of your company.
  • Experiment with different environments. If you’ve worked only in Windows, play with Unix at home (the freely available Linux is perfect for this). If you’ve used only makefiles and an editor, try an IDE, and vice versa.
  • Stay current. Subscribe to trade magazines and other journals (see page 262 for recommendations). Choose some that cover technology different from that of your current project.
  • Get wired. Want to know the ins and outs of a new language or other technology? Newsgroups are a great way to find out what experiences other people are having with it, the particular jargon they use, and so on. Surf the Web for papers, commercial sites, and any other sources of information you can find.

It’s important to continue investing. Once you feel comfortable with some new language or bit of technology, move on. Learn another one.

It doesn’t matter whether you ever use any of these technologies on a project, or even whether you put them on your resume. The process of learning will expand your thinking, opening you to new possibilities and new ways of doing things. The cross-pollination of ideas is important; try to apply the lessons you’ve learned to your current project. Even if your project doesn’t use that technology, perhaps you can borrow some ideas. Get familiar with object orientation, for instance, and you’ll write plain C programs differently.

Opportunities for Learning

So you’re reading voraciously, you’re on top of all the latest breaking developments in your field (not an easy thing to do), and somebody asks you a question. You don’t have the faintest idea what the answer is, and freely admit as much.

Don’t let it stop there. Take it as a personal challenge to find the answer. Ask a guru. (If you don’t have a guru in your office, you should be able to find one on the Internet: see the box on on the facing page.) Search the Web. Go to the library. In this era of the Web, many people seem to have forgotten about real live libraries filled with research material and staff.

If you can’t find the answer yourself, find out who can. Don’t let it rest. Talking to other people will help build your personal network, and you may surprise yourself by finding solutions to other, unrelated problems along the way. And that old portfolio just keeps getting bigger….

All of this reading and researching takes time, and time is already in short supply. So you need to plan ahead. Always have something to read in an otherwise dead moment. Time spent waiting for doctors and dentists can be a great opportunity to catch up on your reading—but be sure to bring your own magazine with you, or you might find yourself thumbing through a dog-eared 1973 article about Papua New Guinea.

Critical Thinking

The last important point is to think critically about what you read and hear. You need to ensure that the knowledge in your portfolio is accurate and unswayed by either vendor or media hype. Beware of the zealots who insist that their dogma provides the only answer—it may or may not be applicable to you and your project.

Never underestimate the power of commercialism. Just because a Web search engine lists a hit first doesn’t mean that it’s the best match; the content provider can pay to get top billing. Just because a bookstore features a book prominently doesn’t mean it’s a good book, or even popular; they may have been paid to place it there.

Tip: Critically Analyze What You Read and Hear

Unfortunately, there are very few simple answers anymore. But with your extensive portfolio, and by applying some critical analysis to the torrent of technical publications you will read, you can understand the complex answers.

Challenges

  • Start learning a new language this week. Always programmed in C++? Try Smalltalk or Squeak. Doing Java? Try Eiffel or TOM.
  • Start reading a new book (but finish this one first’) If you are doing very detailed implementation and coding, read a book on design and architecture. If you are doing high-level design, read a book on coding techniques.
  • Get out and talk technology with people who aren’t Involved in your current project, or who don’t work for the same company. Network in your company cafeteria, or maybe seek out fellow enthusiasts at a local user’s group meeting.

Esse livro é muito bom e tem várias outras dicas importantes como essa que te fazem abrir a cabeça e pensar de formas diferentes. Se você ainda não tem, vá na Amazon agora e compre! (eu não estou ganhando comissão por isso)

10 livros recomendados para desenvolvedores

Thursday, March 27th, 2008

No início do ano escreví um post sobre a importância de nós, desenvolvedores de software, lermos livros, que rendeu boas discussões. Depois disso recebí algumas mensagens perguntando quais são os livros que considero mais importantes para um desenvolvedor.

Bom, essa pergunta é complicada de responder. Primeiro porque eu ainda não lí todos os livros que deveria, e segundo porque cada pessoa tem seu gosto particular por tecnologias, processos, frutas e etc.

Então, resolví criar a lista dos 10 livros que eu particularmente mais gosto e que recomendo fortemente para qualquer desenvolvedor. Estes livros são alguns dos que mais me influenciaram a melhorar minha forma de trabalhar e programar. Além disso, coloquei link para os sites, blogs ou páginas de informações dos autores, caso alguém ainda não tenha:

Agile Software Development, Principles, Patterns, and Practices Agile Software Development, Principles, Patterns, and Practices
Robert C. Martin
Agile Software Development with SCRUM Agile Software Development with SCRUM
Ken Schwaber e Mike Beedle
Design Patterns: Elements of Reusable Object-Oriented Software Design Patterns: Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson e John M. Vlissides
Domain-Driven Design: Tackling Complexity in the Heart of Software Domain-Driven Design: Tackling Complexity in the Heart of Software
Eric Evans
Extreme Programming Explained: Embrace Change (2nd Edition) Extreme Programming Explained: Embrace Change (2nd Edition)
Kent Beck e Cynthia Andres
Introduction to Algorithms Introduction to Algorithms
Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest e Clifford Stein
The Mythical Man-Month: Essays on Software Engineering The Mythical Man-Month: Essays on Software Engineering
Frederick P. Brooks
Patterns of Enterprise Application Architecture Patterns of Enterprise Application Architecture
Martin Fowler
Peopleware: Productive Projects and Teams Peopleware: Productive Projects and Teams
Tom DeMarco e Timothy Lister
The Pragmatic Programmer: From Journeyman to Master The Pragmatic Programmer: From Journeyman to Master
Andrew Hunt e David Thomas

Infelizmente todos os livros são em inglês e nem sei se existe tradução. Se você não souber inglês, matricule-se urgentemente em algum curso porque saber inglês nesta área é muito importante!

Convido vocês a também fazerem suas listas e compatilharem seus livros preferidos :)

Você tem que ler os livros!

Tuesday, January 22nd, 2008

Nos últimos meses já ouví algumas pessoas dizerem que não têm costume de ler livros, ou questionarem a necessidade de lê-los, já que há uma abundância de fontes de leitura por aí na Internet.

Hoje em dia realmente temos milhares de formas de nos informarmos. Me lembro de ter lido em algum lugar que a Internet possui mais de 250 milhões de sites. Se somarmos isso tudo, realmente tem muita informação. Justamente por isso, faz parte da minha rotina diária dar uma navegada no Google Reader, onde tenho cadastrados os feeds de mais de 300 sites e blogs de diversos assuntos que acho interessantes. Essa é basicamente a minha principal fonte de informação diária e é a melhor maneira de me manter atualizado com tantas novidades surgindo por aí todo dia.

Porém, em alguns casos, para aprender e entender certos assuntos, você precisa ler os livros. Não tem jeito! Por exemplo, como é que um desenvolvedor de software pode dizer que entende Domain-Driven Design sem ter lido o livro do Eric Evans ou pelo menos o DDD Quickly? Ou então dizer que sabe sobre metodologias ágeis sem ter lido pelo menos um livro do Ken Schwaber, Kent Beck ou Uncle Bob? Como é que alguém pode se dizer Arquiteto de Software Sênior++ Certified ™ sem ter visto o Patterns of Enterprise Application Architecture e o GoF? Eu respondo: não tem como. Simplesmente não tem jeito, você precisa ler os livros.

Hoje mesmo o Patrick Kua, que trabalha na ThoughtWorks, escreveu um post sobre os livros que ele considera essenciais para saber sobre metodologias ágeis. Ele acredita que você precisa ler 11 livros, O.N.Z.E. livros, para entender sobre o assunto, e ainda completa: “Of course, simply reading the books won’t mean that you’re an expert [...] though it’ll definitely help in providing context, advice or skills that you need to practice.”. Ou seja, mesmo lendo todos esses livros, ainda há muita coisa para aprender… E estamos falando sobre um assunto apenas.

Assim como os blogs e os sites, os livros são uma fonte de informação importantíssima e necessária. Se você quer trabalhar com tecnologia e desenvolvimento de software não tem jeito: tem que ler e ler muito!

Now, discover your strengths: StrengthsFinder 2.0

Saturday, September 22nd, 2007

Livro - StrengthsFinder 2.0Depois de ler no blog do Nick Carroll fiquei extremamente curioso para fazer o teste do StrengthsFinder. Ontem finalmente o meu livro chegou e como é bem curtinho já acabei com ele!

Resumindo, o StrengthsFinder é um teste que serve para te ajudar a descobrir quais são os seus melhores “talentos” naturais. Uma pesquisa feita pelo Gallup International Research & Education Centre mostra que as pessoas têm resultados muito melhores quando se focam em melhorar seus talentos naturais ao invés de tentarem melhorar as áreas que são mais fracas.

Segundo o autor Tom Rath, Capacidade = Talento x Esforço. Não importa o quanto você se esforçar, se você não se esforçar nas coisas certas nunca conseguirá ser excepcionalmente bom. Focando e desenvolvendo suas melhores qualidades você terá muito mais chances de crescer profissionalmente e como pessoa.

Os pesquisadores que desenvolveram o teste identificaram e catalogaram 36 qualidades básicas que as pessoas podem ter. O teste de 177 perguntas te mostra quais são suas 5 maiores qualidades/talentos e te dá um relatório personalizado das atitudes que você pode ter para estimular o desenvolvimento do seu talento. O resultado do meu teste foi o seguinte:

  • Futuristic: People who are especially talented in the Futuristic theme are inspired by the future and what could be. They inspire others with their visions of the future.
  • Achiever: People who are especially talented in the Achiever theme have a great deal of stamina and work hard. They take great satisfaction from being busy and productive.
  • Analytical: People who are especially talented in the Analytical theme search for reasons and causes. They have the ability to think about all the factors that might affect a situation.
  • Competition: People who are especially talented in the Competition theme measure their progress against the performance of others. They strive to win first place and revel in contests.
  • Responsibility: People who are especially talented in the Responsibility theme take psychological ownership of what they say they will do. They are committed to stable values such as honesty and loyalty.

Livrinho rápido, barato (US$ 10) e interessante. Vale a leitura :)

Asshole-Driven Development

Thursday, June 21st, 2007

Isso mesmo: desenvolvimento guiado por idiotas.

Scott Berkun, autor do livro The Myths of Innovation (que está na minha fila de livros para ler) escreveu um post muito bem humorado no seu blog, entitulado Asshole-Driven Development. Ele descreve várias “metodologias” de desenvolvimento de software amplamente utilizadas em várias empresas (pelo visto não só no Brasil).

A metodologia que eu mais gostei foi essa:

Asshole Driven development (ADD) – Any team where the biggest jerk makes all the big decisions is asshole driven development. All wisdom, logic or process goes out the window when Mr. Asshole is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway.