I love Software Development, because it’s very collaborative and communicative

I often have the feeling that programming and software development is largely misunderstood. Many people seem to still have ancientbelieves about how software development works. Believes potentially scaring them away from pursuing a career in software development. Let’s fix this.

In this blog post I’ll show why the mental image of one person sitting in a cellar all by him-/herself is as wrong as it can be. I’ll explain why I believe that the most important ability of a software developer is his/her ability to communicate.  And I’ll highlight why I enjoy software development so much. (hint: there are also slides about this)

The typical misunderstanding

Let me take you through a somewhat normal conversation for me with strangers at a party:


Bingo! You’ve just won yourself a speech of how that is basically the opposite of what I do. My work is filled with lots and lots of communication. Let me walk you through some of the most important and most frequent communication activities in Software Development.

Communication within the team

Team Spirit, December 2006
Team Spirit, December 2006 (Photo credit: JF Schmitz)

Most software isn’t built by a single developer. It’s developed by a team or even multiple teams. I mean does anyone really believe that a single nerd in a cellar builds Facebook and another one builds Windows?

This software is built by large collaborative teams. In a team you have to work together to achieve something.The parts developed by members of the team have to interact and play nice with each other. To Facilitate this the authors have to communicate. As software often solves complex problems, these systems also have to be carefully designed. This is best done in a group of people in front of a whiteboard – not in front of a monitor.

Modern software development actually focuses a lot on the team developing software and how they work together. Let’s take a look at the Manifesto for Agile Software Development, the foundation of most modern software development processes. It values:

Individuals and interactions over processes and tools

This is the very first point made highlighting that good software development is about people and how they work together. It’s not only communicating about the project, solving difficult problems together – of course the normal small talk and “grab a drink together after work” is included as well😉 Motivation is very important.

It doesn’t stop here though. Often software projects are big enough that multiple teams have to collaborate to realize them. There is a lot of communication going on there as well. But there are still other people developers should communicate with like the system administrators and the customers. Wait, what – the customers?

Communication with the customers

Yep the customer. The ones ultimately using the applications. Or the client wanting the application.

Unfortunately that thought might seem alienating at first, but think about it. Those are the people who ultimately know what the application should do. They are the ones that will be using it, it should fit their purposes. The only way to know if the application reaches its highest goal, satisfying the customer, is through frequent communication and thereby feedback. That starts with asking them what the application should do and how it will be used. It doesn’t stop there though, it is enhanced through demos of a prototype of the application to verify understanding.

Some people take this even one step further. In one of the all time classic books about programming, The Pragmatic Programmer, it is recommended that you spend as much as one week working with the your users before writing an application. This way you should get to know what their work is like.

All of this generates invaluable insights and builds trust.

Look, there are two of them in front of just one monitor!

A friend and me doing some Pair Programming

Yep that’s two developers in front of just one monitor. Actually it’s me and a good friend of mine. So what do we do? Well naturally we are working. We are doing Pair Programming. That is one of us is actually writing the code while the other one observers. We both design the code and talk about it. We work together.

Some people think that this is a waste of time. Hell those are 2 programmers, give them 2 PCs so they can write twice as much code!

It’s not as simple as that. In software development we constantly solve problems. Solving them together leads to a solution sooner, higher quality code and more knowledge spread across the team. The benefits of Pair Programming are worthy of a whole blog post of their own.

Despite the benefits Pair Programming is still a pretty debated topic. Some people despise it. Some people only apply it to difficult problems. Some people say that all production code must be written in Pair Programming.

For me I love Pair Programming: It makes programming a lot more enjoyable, at least to me. When you try to solve a complex problem sometimes you hit the wall. You just don’t know how to solve this problem. You’ve run out of options. It can be really frustrating. That never happens to me when I’m Pair Programming. We, as a team, never seem to run out of ideas on how to solve a given problem until we find one that works. On top of that I can communicate and collaborate with someone all the time. How much more awesome can it get?

And what’s my point with this? During a good normal work day, I actually communicate and collaborate with at least one person almost all the time. Sweet.

Communicating through code

Now I really gotta be kidding right? What does code have to do with communication?

A lot actually. Let’s see what Kent Beck says in his book “Smalltalk Best Practice Patterns” in the Introduction chapter:

“(…) when you program, you have to think about how someone will read your code, not just how a computer will interpret it.”

Kent Beck

And that someone refers to the people in your team as well as yourself. As a team you work together meaning that you have to be able to understand and extend the work of your colleagues. And of course you must be able to understand what you wrote some months ago or even just some weeks ago. You might be surprised how difficult this can get with poorly written code.

Good code must communicate well. The best code, in my eyes, is the code that is the easiest to understand. Code that pretty much speaks to its readers. Writing such code can be very challenging. You can find me discussing with my Pair Programming partner about naming questions for like 2 minutes – it is important.

(Taken from OSNews)

Does everyone work like that?

Not every company empowers their teams. Not everyone loves pair programming. Not every company cherishes communication. Not every company works Agile. There are people out there still following the Waterfall process, which has been a misunderstanding from the beginning, where at first rigorous documents are made and then the programmers are locked away to “just code it”. Why do people keep doing this? I have no idea. I just know that there are enough tech companies looking for developers out there so you don’t have to end up at an old-school command & control enterprise.

So with all this talk about communication one might ask: “What about the introverts? What about people who don’t like to talk as much?”

Well I’ve worked with some people who might qualify as introverts. Let me tell you this: I’d love to work with each and every one of them again.

See communication is not a one-way street. It’s not just about talking, it’s at least as much about listening. People who just talk but don’t listen are bad communicators. Maybe more introverted people don’t talk as much. However with the ones I know I found that if they say something it is of immense value. And they are very good listeners as well. Plus they enjoyed Pair Programming as much as I did. I would say they are good communicators and collaborators. To me bad communicators and collaborators are those that don’t work together with the team and spend most of their time simply criticizing others.

Wrapping up

Look we got post-its too! (Thanks for the photo to Andreas!)

So what’s the lesson here? Well today’s Software Development is a lot different from what many people think it is. You work together as a team. You talk. You draw on white boards. You have those funny little post-its to coordinate work. Some people work together all day long. You have fun. You actually communicate with he people using your product.

As I hinted at first all this makes me believe that the ability of developer to communicate is more important than his/her technical ability. Developers are part of a team. If they excel technically but don’t know how to share their expertise with the team then they’re not helping much. Even worse, people who spend meetings just criticizing ideas can easily kill the motivation of a team and slow them down significantly. Luckily I haven’t met many of them.

Good communicators and collaborators on the other hand do everything for the team. They help and motivate each other. They happily share their knowledge and are always ready to learn new things.

So my point is this: Do you like solving problems? Do you like to work in a team? Would you like to work in a continuously evolving field with lots of new technologies and opportunities? Do you like to build something awesome helping many people?

Congratulations, software development might be just the thing for you!



I would love to do something funny or happy for my fiance. I’ve thought about that for so long but didn’t figure out what i should take in my writing or translating.

I know that he loves coding and solving the problems. He is a kind of must-done things person before coming home from work. How enthusiasm he is!

Honey, today my work is about your passion :). Hope you will love it. :P.

———————————- ———–

Tôi yêu thích việc phát triển phần mềm bởi nó là mang tính gắn kết và có sự lan truyền lớn.

Tôi luôn có cảm giác rằng việc phát triển các phần mềm và chương trình vẫn bị hiểu một cách chưa chính xác. Nhiều người dường như vẫn có những quan điểm cổ hủ về việc phát triển phần mềm diễn ra như thế nào. Niềm tin này dẫn tới sự sợ hãi tiềm ẩn khiến cho họ không tới đạt được một sự nghiệp thành công trong lĩnh vực phát triển phần mềm. Hãy cùng xem lại những điều này!

Những hiểu lầm thường gặp

Để tôi cho bạn xem qua một cuộc đối thoại thông thường giữa tôi và một vài người bạn mới gặp tại một bữa tiệc:

– Tobi, còn mày thì làm gì?

– Tao học kĩ sư phầm mềm.

– À, kiểu một thằng cha cô đơn suốt ngày ngồi trong phòng ấy hả?


Đấy, bạn vừa tự mình nói ra chính xác những gì trái ngược hoàn toàn với công việc của tôi.

Công việc này đòi hỏi rất nhiều sự trao đổi, đối thoại. Để tôi cho bạn thấy những hoạt động đối thoại quan trọng và thường gặp nhất khi viết các phần mềm.

Sự trao đổi giua các thành viên trong nhóm.

Hầu hết các phần mềm được viết lên không phải bởi một cá nhân riêng lẻ. Chúng được tạo nên từ công sức của cả một nhóm thậm chí là nhiều nhóm nhỏ. Ý tôi muốn nói ở đây là liệu có ai thực sự tin rằng một tên nghiện máy tính suốt ngày nhốt mình trong phòng đã tạo ra Facebook hay một người khác thì viết ra Windows? Thật ra thì đối với những super man thì có thể nhưng thời đại hiện nay để ra một sản phẩm hoàn hảo thì không thể solo từ đầu tới cuối được

Phần mềm này được viết ra bởi cả một nhóm lớn có sự phối hợp chặt chẽ với nhau. Trong nhóm, bạn phải kết hợp cùng nhau để tạo ra hiệu qủa trong công việc. Các phần được làm bởi thành viên trong nhóm phải được tương tác qua lại và phối hợp tốt với nhau. Để làm mọi việc diễn ra thuận lợi thì những người viết ra phần mềm phải trao đổi với nhau. Khi các phần mềm cần xử lí những vấn đề phức tạp thì hệ thống càng cần phải được thiết kế một cách chặt chẽ. Hiệu qủa tối ưu chỉ được tạo ra giữa những con người cùng ngồi trước một chiếc bảng trắng chứ không phải trước một cái monitor. Để hiểu một cách đơn giản thì có thể hiểu họ phải trao đổi idea với nhau, viết trên bảng để mọi người cùng xây dựng chứ không phải ngồi làm việc bên một cái monitor mà không trao đổi j

Việc phát triển phần mềm hiện đại thực chất tập trung rất nhiều vào việc làm theo nhóm cũng như cách họ làm việc cùng nhau như thế nào. Hãy cùng nhìn vào tuyên ngôn cho việc phát triển phần mềm Agile, nền tảng cho quá trình phát triển của hầu hết những phần mềm hiện đại. Theo đó là:

– Đặt các cá nhân và sự tương tác lên trên qúa trình xử lí và công cụ.

Điểm đầu tiên đáng nói tới để tạo nên thành công của việc phát triển một phần mềm chính là con người và sư phối hợp trong công việc. Không chỉ trao đổi về dự án, cùng nhau giải quyết các vấn đề khó khăn mà bên cạnh đó còn có cả những trao đổi ngoài lề hay uống vài li sau khi kết thúc công việc. Tạo động lực cho công việc rất quan trọng. :). Ngoài lề một chút, ở Nhật thứ 6 người ta gọi là 話金(はなきん ) – ngày để mọi người uống với nhau và chia sẻ những chuyện bên lề sau một tuần làm việc. Do đó, sẽ không thiếu những cảnh cô gái và chàng trai say sưa trên các chuyền tàu 😎

Không chỉ có vậy. Thường thì các dự án lớn cần có sự cộng tác của nhiều nhóm để gỉai quyết. Vì thế nên việc tương tác diễn ra nhiều hơn. Tuy nhiên vẫn có những người khác mà các developer cần tiếp xúc đó là những người điều hành hệ thống hay khách hàng.

Làm việc cùng khách hàng

Chính xác là khách hàng. Những người cuối cùng sử dụng các ứng dụng đó. Hoặc những đối tác muốn sử dụng các phần mềm này.

Đáng tiếc là việc nghĩ đến những điều này ngay từ đầu đã rất khó chịu nhưng hãy cùng đề cập tới nó. Đây là những người cuối cùng biết các ứng dụng này dùng để làm gì. Họ là những người cuối cùng sử dụng chúng phục vụ cho những mục đích của mình. Cách duy nhất để biết được ứng dụng đó có đạt được hiệu qủa tối ưu hay có thỏa mãn được nhu cầu của khách hàng hay không chính là thông qua việc trao đổi thường xuyên và nhận những phản hồi trực tiếp từ khách hàng. Điều này bắt đầu bằng việc hỏi họ phần mềm sử dụng để làm gì và dùng như thế nào. Việc này cũng không dừng tại đây, việc nâng cao hiệu qủa sử dụng thông qua việc chạy thử một loạt các demo để kiểm tra việc hiểu cách sử dụng ứng dụng này như thế nào. Thường thì quy trình là hàng tháng sẽ demo 1 lần, nhận feedback từ khách hàng, cải tiến nó và hoàn thiện cho tới khi release

Một số người còn đưa điều này tới một bước xa hơn. Trong một cuốn sách kinh điển về lập trình The Pragmatic Programmer đã đưa ra gợi ý bạn nên sử dụng ít nhất một tuần với người dùng trước khi bắt tay vào việc viết ứng dụng. Bằng cách này bạn sẽ hình dung ra được công việc mình cần làm như thế nào.

Tất cả những điều này sẽ tạo ra được lòng tin và gía trị vô gía từ bên trong.

Xem kìa, có hẳn hai người ngồi trước chỉ một cái máy tính!

Đúng là hai developers đang ngồi trước một màn hình máy tính. Thật ra đó là tôi và một người bạn của mình. Chúng tôi đang làm gì? Cùng nhau làm việc. Cái này gọi là Pair Programming. Một người code trong khi người còn lại sẽ quan sát theo dõi. Cả hai cùng viết code và thảo luận về chúng. Chúng tôi cùng nhau làm việc.

Một vài người cho rằng điều này chỉ làm lãng phí thời gian. Thế quaí nào mà có những hai người làm thì đưa cho họ hai cái máy tính chẳng phải họ sẽ code hiệu qủa gấp đôi sao?

Nhưng moị thứ không hòan toàn đơn gỉan như vậy. Trong việc phát triển phần mềm, chúng tôi liên tục phải gỉai quyết các vấn đề phát sinh. Cùng nhau tìm hiểu sẽ đưa ra được gỉai pháp sớm hơn, chất lượng code tốt hơn và kiến thức được chia sẻ tới các thành viên trong nhóm nhiều hơn. Hiệu qủa của việc Pair Programming là rất đáng kể.

Mặc dù vậy thì những lợi ích của việc này vẫn còn là một đề tài gây nhiều tranh luận. Một số người không coi trọng việc này, họ chỉ áp dụng chúng đối với một số vấn đề qúa khó.

Đối với riêng cá nhân tôi thì việc làm theo nhóm đôi này khá hứng thú, ít nhất với tôi là như vậy. Khi bạn phải xử lí một vấn đề qúa phức tạp sẽ có lúc bạn cảm thầy như đi vào ngõ cụt và bế tắc. Bạn chẳng biết phải làm thế quaí nào. Ý tưởng cạn kiệt. Thực sự trở nên bất lực. Điều này chẳng bao giờ xảy ra với tôi khi Pair Programming. Chúng tôi, khi làm việc theo team thì không bao giờ hết các ý tưởng cho việc giải quyết vấn đề đến khi chúng tôi tìm ra được gỉai pháp thích hợp nhất thì thôi. Quan trọng hơn cả của điều này là lúc nào tôi cũng được trao đổi với một ai đó trong suốt qúa trình làm việc. Còn gì tuyệt hơn thế nữa không? Thật ra với tôi, lập trình như giải một bài toán. Nếu một mình làm thì cũng sẽ có cách giải quyết nhưng nếu làm theo nhóm thì sẽ chia sẻ và học được của người khác những cách giải khác. Việc đó làm tăng khả năng chuyên môn lên rất nhiều. Một bài toán khi giải được bằng nhiều cách thì với việc làm theo nhóm sẽ giúp cho chúng ta tìm được cách giải tối ưu nhất. Lập trình không chỉ kết thúc ở việc chương trình đã chạy, đáp ứng đủ yêu cầu khách hàng mà còn phải làm cho nó chạy thật tối ưu, đưa ra kết quả chính xác và nhanh chóng. Nếu bạn luôn mong muốn tối ưu chương trình của mình thì bạn chính là một developer giỏi còn không thì bạn vẫn chỉ dừng lại ở mức coder mà thôi. Code for fun and you will be get food 😍!!!

Điều tôi muốn chỉ ra ở đây là gì? Đó chính là trong suốt cả ngày làm việc tôi luôn phải trao đổi và kết hợp với ít nhất một người. Điều đó là rất tuyệt!

Giao tiếp thông qua code

Bây giờ thực sự là tôi đang tào lao về việc này? Code thì làm được gì trong giao tiếp?

….” khi bạn đang viết một chương trình, bạn phải nghĩ rằng có ai đó sẽ đọc code của bạn như thế nào thay vì một cái máy tính sẽ hiểu chúng ra sao”.

Kent Beck.

Đó cũng là việc mà một người có mối liên hệ chặt chẽ đối với các thành viên khác trong team cũng như với chính bạn. Khi làm việc theo nhóm điều này đồng nghĩa với việc bạn phải có khả năng hiểu được và đảm nhận thêm được cả những công việc của đồng nghiệp. Và lẽ đương nhiên là bạn bắt buộc phải hiểu những gì mình đã viết ra vài tháng trước hay đơn gỉan là vài tuần trước. Bạn sẽ ngạc nhiên khi thấy điều này trở nên khó khăn thế nào đối với những phần code được viết rất kém.

Code tốt phải có khả năng giao tiếp tốt. Phần code tốt nhất, theo cá nhân tôi là code dễ hiểu nhất. Code nói lên rất nhiều về người đọc nó. Viết ra được những code như vậy là một thử thách lớn. Và thực ra đoạn code sẽ nói lên tính cách và trình độ của người viết nó. Đó là lý do tại sao các công ty tuyển dụng thường bắt bạn show ra đoạn code bạn viết

( Something funny no need to translate :P)


Có phải ai cũng làm việc kiểu này?

Không phải lúc nào làm việc theo nhóm cũng hiệu qủa. Không phải ai cũng thích làm việc theo cặp. Không phải công ty nào cũng thích đối thoại. Không phải công ty nào cũng làm việc theo Agile. Có rất nhiều người ngoài kia vẫn làm theo quy trình Waterfall, một điều lầm lẫn ngay từ bước khởi đầu nơi mà những tài liệu chính xác chặt chẽ được tạo ra và những người lập trình bị kìm chặt bởi yêu cầu ” code cái đó đi”. Tại sao mọi người vẫn tiếp tục làm như vậy? Tôi chẳng hiểu lí do vì sao. Tôi biết là có đủ các công ty về công nghệ đang tìm kiếm những developers ngoài kia và bạn không cần phải kết thúc tại một công ty đã trở nên lỗi thời.

Với tất cả những gì tôi vừa đề cập tới về giao tiếp thì có người sẽ hỏi rằng “Vậy những người hướng nội thì sao? Những người không thích phải nói qúa nhiều?”

Chúng tôi đã làm việc với một vài người được xem là những người hướng nội. Để tôi cho bạn biết một điều là tôi rất thích làm việc với những người này và có nhiều hứng thú để làm việc tiếp với họ.

Đối thoại không phải là con đường một chiều. Nó không chỉ bao gồm việc nói, ít nhất nó cần được đề cập tới là việc lắng nghe. Những người mà chỉ nói và không lắng nghe là những người giao tiếp kém. Có thể những người hướng nội thì nói không nhiều. Tuy nhiên đối với những người mà tôi biết thì tôi thấy rằng bất cứ khi nào họ nói một điều gì đó thì chúng đều rất có gía trị. Họ đồng thời là những người rất biết lắng nghe. Thêm nữa họ cũng thích làm việc theo cặp như tôi. Tôi có thể nói rằng họ chính là những người giao tiếp và cộng tác tuyệt vời. Đối với tôi những người giao tiếp kém và những cộng sự tồi chính là những người kém trong làm việc nhóm và sử dụng chủ yếu thời gian của họ để soi xét đánh gía người khác.

Tóm lại

Bài học rút ra ở đây là gì? Ngày nay việc phát triển phần mềm đã khác nhiều so với cách mọi người vẫn nghĩ trước kia. Bạn làm việc theo nhóm. Bạn trò chuyện. Bạn viết lên bảng. Bạn làm những thứ buồn cười để khiến cho việc hợp tác trở nên vui vẻ. Có những người làm việc cùng nhau suốt cả ngày. Có những người làm việc trực tiếp với khách hàng sử dụng sản phẩm của mình.

Như đã nói ngay từ đầu thì tôi tin rằng khả năng kết nối của một developer quan trọng hơn cả năng lực về kĩ thuật của anh ta. Developers là một phần của nhóm. Nếu họ vượt trội hơn về mặt kĩ thuật nhưng không biết cách chia sẻ khả năng chuyên môn của mình với cả nhóm thì điều này cũng không tạo ra hiệu qủa lắm. Và tệ hơn nữa là có những ngừoi dùng thời gian vào việc phân tích các ý tưởng sẽ làm mất đi tinh thần của cả nhóm và kéo cả nhóm đi xuống một cách đáng kể. May mắn thay là tôi không gặp nhiều người như vậy.

Những người đối thoại và cộng sự tốt đồng thời còn làm tất cả mọi thứ vì cả nhóm. Họ giúp đỡ và động viên những người khác. Họ vui vẻ chia sẻ những hiểu biết của mình cũng như luôn luôn sẵn sàng học hỏi điều mới.

Điều tôi muốn nói ở đây là: Bạn có muốn gỉai quyết các vấn đề không? Bạn có thích làm việc theo nhóm? Bạn có thích làm việc trong một môi trường không ngừng thay đổi với những công nghệ và những cơ hội mới? Bạn có muốn tạo ra những thứ tuyệt vời hỗ trợ cho con người?

Xin chúc mừng, phát triển phần mềm có thể chính là thứ dành cho bạn!

Bạn nhà mình đi làm lúc nào cũng miệt mài, thương bạn nhiều ghê. Dịch cái đoạn nhỏ nhỏ xinh xinh này cho bạn vui. For my super super cool software developer. :D. ❤