Posts tagged as:

experience

Here’s the link to the pledgie where you can help me get to RubyConf. Click here to lend your support to: Send Charles to RubyConf and make a donation at www.pledgie.com !

This week’s episode is an interview with Corey Haines. He’s pretty well known as the Software Journeyman and his coding tours where he traded time pairing on code for room and board.

You can keep up with him at http://coreyhaines.com.

You can also check out the following links for other things he’s doing:

Here’s a link to the Software Craftsmanship Manifesto which is tied a lot to the discussion we had on Software Craftsmanship.

Corey mentioned the Structure and Interpretation of Computer Programs – 2nd Edition (MIT Electrical Engineering and Computer Science)
book, which is a mind-blowing set of instruction and exercises for computer programmers.

We also discussed pairing in relation to the code retreats. Corey mentioned the paper by Arlo Belshee called “Promiscuous Pairing and the Beginner’s Mind”

You can reach Corey on twitter as @coreyhaines and by email at coreyhaines@gmail.com

Finally, checkout the latest news on the XP Universe conference.

Download this Episode

{ 1 comment }

This year’s Agile Roots conference is focused on building great software. They have a terrific line up of speakers and it only costs $250, which makes it a great deal! The conference this year focuses on the development process and how it formulates requirements that lead to great software. Not just great software to maintain and build. But also great software that provides value to users.

Andrew explained that we, as developers, need to realize that we’re enabling a business experiment, not just building code.

He also went into the value we receive from open source software. The problem some of these people have is collecting the value of their work. You don’t get paid for being smart. Rather, we need to find ways to receive value from what we’re providing, even if it’s not designed specifically to make us money.

Pat Maddox wrote a blog post called “Are you punching your users in the face?” It was designed to help people to understand was that the value of the code isn’t in the tests or the code itself. Its value is in building software that users want to use.

We got a great recommendation to read “A Big Ball of Mud”. The author asked “What do you call someone who writes code like this?” after talking about every antipattern and code nastiness and he said “millionaires.” Historically this is true. Someone solved someone else’s problem with ugly hacky code, and walked away with millions of dollars.

We tend to discount sales and marketing personnel, when they are the ones that make your money. They build the brand and they bring the money in, even if you don’t have the best products.

Tim O’Reilly said, “Create more value than you capture.” If you do this your users will love you and your community will grow and support you.

We go into the idea economy and how agile ties into the idea economy. People are trying to sell each other on their ideas in agile as much as anything else.

Andrew was first introduced to Agile he found most of the practices as wasteful, painful, and wrong. So, he started discovering the roots of Agile. What he found was that Agile was bout solving our problems with our strengths. Once he started going to the Agile Round Table, he found that it was actually about delivering working software.

Over the last year and a half, Andrew has been working on taking agile into other areas of work.

The term ‘agile’ has become overloaded. Some people say agile, what most people mean is a watered down half implemented version of scrum.

Agile, the word, has crossed the chasm. The practices haven’t.

Trying to agile isn’t what you should do. You should be trying to be awesome.

Listen to the interview for some great tips on being awesome.

Here are some links to following Andrew:

Twitter: littleidea

Blog: http://stochasticresonance.wordpress.com/

Download this Episode

{ 0 comments }

This episode of the teachmetocode podcast, Dave talks us through the process he and Andy Hunt went through in founding the Pragmatic Programmers book series and publishing company. Dave also talks about the the advantages that they have had by not holding onto or being mired down by the way things have always been done and their growth in non-conventional book selling channels.

He also mentioned that if you would like them to come do training where you’re at, contact Mike Clark and find people who are willing to sit in on the course.

I think my favorite part of the interview was his explanation of where the Agile Manifesto came from. We also got to talk about what Agile development really is.

Dave explains the correlation between his musical interests and his programming interests. He figures that at least 30-40% of speakers at any conference would have some sort of musical background. The structure and the way things come together in music actually applies to software. You create patterns or structures that work well together at multiple levels.

Toward the beginning of the Pragmatic Programmers, Dave and Andy recommend learning a new language every year. He discusses his hobby of picking up new programming languages and investing in yourself.

Finally, I asked Dave about running a business and how to get one started. He gave some terrific advice regarding building your own application and business.

He wrapped up the episode by pointing out that programming is exceptionally hard. You have a huge amount of information you have to know in order to get into programming. On top of it, the world is complicated and makes the problems we have to solve hard. So, ultimately, make it fun!

Download this Episode

{ 16 comments }

This week’s episode on pair programming discusses where you might see pair programming, HashRocket’s pairing setup, perceived and real disadvantages to pair programming, its advantages, and what it takes to do good pairing.

Pair programming is usually associated with Extreme Programming. It is sometimes seen as a mentoring practice, but is actually a collaboration practice, not a mentoring practice. This is because both programmers participate equally, not one leading and the other following for long durations. Pair programming is done with 1 computer and 2 programmers. I’ve never seen it work well with 2 computers and 2 programmers unless one computer was being ignored or under-utilized.
[click to continue…]

{ 2 comments }

In this episode, Chad discusses how he broke out of a comfortable job as a forklift operator, which ultimately led to him becoming a programmer.

He discusses his job, Ruby Central, and the Pragmatic Studio as contributions he makes to the community.

We also discuss the ebb and flow of passion for programming and how to avoid burnout on the things that we love. [click to continue…]

{ 4 comments }

This week I interviewed Chad Fowler. He and several others have helped organize Ruby conferences around the world, most notably RailsConf, RubyConf, and RubyConf India. He has also written The Passionate Programmer and Rails Recipes. Finally, he has contributed to open source projects like RubyGems and Facebooker.
[click to continue…]

{ 1 comment }

Download this Episode

In this episode, we discuss why your application needs tests. Here’s a summary of the thoughts given in this episode:

Why you should test:

1. You know your code works the way you expect.
2. You guarantee that later changes to your code don’t break existing functionality.
3. It documents your code. [click to continue…]

{ 0 comments }

In order to contribute as an employee or a freelance developer, we need to understand the nature of business. Specifically, we need to understand the nature of how our employer or client makes money so we understand our contribution and so we recognize where our value is.

Once we understand the nature of business, we can look for other pain points people are facing and find ways to solve those problems. That’s how we get paid.

[click to continue…]

{ 5 comments }

This week’s episode is about work fulfillment. To start out, I provide context for my experience by briefly reviewing my work history. Then we go into the 6 things that I believe are critical to a great job. The 6 P’s that define a great job:

  • Passion
  • Purpose
  • People
  • Progress
  • Project
  • Pay

[click to continue…]

{ 4 comments }

Here is the link to my blog post about coding exercises.

Here’s a short list of the coding exercises that are out there.

Here’s an awesome example of a code kata: http://charlesmaxwood.com/8-lessons-from-corey-haines-performance-kata/

Programming exercises are terrific with a mentor. Check out the episode on mentors.

Download this Episode

{ 1 comment }