About a year ago, I wrote out some principles for web programming in PHP. I called it the MicroPHP Manifesto. The thing is, what I talked about wasn’t really specific to PHP. So, I’ve decided to explore the concepts again in the context of the other languages I work with.
What follows are some principles I try to keep in mind.
I like PHP, Python, and JavaScript, and I like making things in PHP, Python, and JavaScript. I’m not a Symfony developer, or a Django developer, or a jQuery developer.
I think this is an important distinction. It’s entirely possible to be a jQuery developer, but not a JavaScript developer. It’s possible to be a Django developer, but not a Python developer. Those are all certainly valuable and useful tools, but if I only know how to use one framework, my options for using the right tool for the job get pretty limited, and in my experience, large, full-stack frameworks are often not the right tool, particularly if flexibilty and performance are major concerns.
My experience has been that I become a better, more versatile developer when I focus on learning a language first. Diving head-first into a full-stack, complex framework when I’m starting out has allowed me to build finished products more quickly, but it also becomes a detriment when I need solutions outside of the framework’s scope. I often end up with a “plug and pray” approach to development, where I find a library or plugin that sounds like it will meet my needs, cross my fingers, and shove it in. That might get my app launched faster, but it makes stuff a lot harder down the road.
Additionally, learning a full-stack framework can be as complex as learning a new programming language. They often have complex architectures and nomenclatures — parts that don’t carry over to other frameworks and tools. I’d rather spend my time learning more about the language itself, knowing the skills that I learn will apply to anything I build in the language, no matter which libraries I use.
Small units of code are good. The smaller it is, the easier it is to understand. It’s harder to screw it up — and I screw stuff up a lot, so limiting that is really important.
So, I strive to build small modules of code with a single purpose, or at most a few closely-related purposes. They should be self-contained pieces that solve individual problems. These pieces then work together to solve larger, more complex problems.
With simpler, modular code, fixing bugs is easier, because I can look at an individual piece and see clearly what it’s doing. And, if the modules are self-contained, testing my code is much easier.
To paraphrase Biggie Smalls, “more code, more problems.”
I want to manage less code. Larger codebases get harder to manage. Searching across the codebase takes longer. Navigating through complex file structures takes longer. Tracing execution through dozens of files is hard. Keeping it all straight in my brain gets challenging.
Bigger libraries and longer code seem to overflow my brain buffer. I have trouble keeping track of code flow when the source gets too long, or when execution is jumping between several source files, and visual noise really affects me, too. This is why I love syntax coloring so much, and consistent whitespace really helps. I use the code folding feature in my editor a lot, just to hide things, so I can focus better on the task at hand.
I also want to support less code. I’m responsible for all of the code that my app uses, not just the stuff I wrote — every single line of it. This means that bugs and security holes are my responsibility. How often do we see a WordPress or Drupal plugin get abandoned after a year or so? Am I sure I want to use a piece of code I don’t really understand, when a year down the road I may have to fix an exploit in it?
This is not to say that I would never use code that I didn’t write — I’d be hard-pressed to get much done that way, and frankly there are better programmers out there than me — but every line of code in my app matters, so I need to justify each one.
I want code that is easy to understand. Understanding things quickly means getting stuff done faster. My time to productivity is shortened. My time to fix bugs is shortened.
I also want code that is easy to verify. My code should be testable, whether or not I get around to actually writing those tests, and I’ve consistently found that simpler, more modular code is more testable.
Readability should be a feature. Code should be simple and terse, but clear. Value clarity over cleverness. When I’m writing code, I try to consider how quickly another developer will be able to understand it at first glance. Alternately, will I be able to understand it when I come back to it in two months? The less time I waste trying to figure out how things work, the more there will be for getting things done.
I’d be lying if I said I always follow these principles. Sometimes, I just get lazy. Sometimes, time constraints mean I write hacky, complex code as fast as possible to get something working, or I pull in a library without reviewing it carefully, and hope it works. In the short term, writing simple, clear code is harder — it requires more discipline and frequent reassessment of technique. Particularly with time-sensitive projects, it’s hard to ever feel like I ever am entirely happy with the results.
But, when I make the time and put the effort in, it always pays off down the road — not just for myself, but for the other members of my team and people who use the code I’ve written, and that’s a really good feeling.
What follows are some principles I try to keep in mind.
Learn languages, not frameworks
I like PHP, Python, and JavaScript, and I like making things in PHP, Python, and JavaScript. I’m not a Symfony developer, or a Django developer, or a jQuery developer.
I think this is an important distinction. It’s entirely possible to be a jQuery developer, but not a JavaScript developer. It’s possible to be a Django developer, but not a Python developer. Those are all certainly valuable and useful tools, but if I only know how to use one framework, my options for using the right tool for the job get pretty limited, and in my experience, large, full-stack frameworks are often not the right tool, particularly if flexibilty and performance are major concerns.
My experience has been that I become a better, more versatile developer when I focus on learning a language first. Diving head-first into a full-stack, complex framework when I’m starting out has allowed me to build finished products more quickly, but it also becomes a detriment when I need solutions outside of the framework’s scope. I often end up with a “plug and pray” approach to development, where I find a library or plugin that sounds like it will meet my needs, cross my fingers, and shove it in. That might get my app launched faster, but it makes stuff a lot harder down the road.
Additionally, learning a full-stack framework can be as complex as learning a new programming language. They often have complex architectures and nomenclatures — parts that don’t carry over to other frameworks and tools. I’d rather spend my time learning more about the language itself, knowing the skills that I learn will apply to anything I build in the language, no matter which libraries I use.
Build small things
Small units of code are good. The smaller it is, the easier it is to understand. It’s harder to screw it up — and I screw stuff up a lot, so limiting that is really important.
So, I strive to build small modules of code with a single purpose, or at most a few closely-related purposes. They should be self-contained pieces that solve individual problems. These pieces then work together to solve larger, more complex problems.
With simpler, modular code, fixing bugs is easier, because I can look at an individual piece and see clearly what it’s doing. And, if the modules are self-contained, testing my code is much easier.
Less code is better than more
To paraphrase Biggie Smalls, “more code, more problems.”
I want to manage less code. Larger codebases get harder to manage. Searching across the codebase takes longer. Navigating through complex file structures takes longer. Tracing execution through dozens of files is hard. Keeping it all straight in my brain gets challenging.
Bigger libraries and longer code seem to overflow my brain buffer. I have trouble keeping track of code flow when the source gets too long, or when execution is jumping between several source files, and visual noise really affects me, too. This is why I love syntax coloring so much, and consistent whitespace really helps. I use the code folding feature in my editor a lot, just to hide things, so I can focus better on the task at hand.
I also want to support less code. I’m responsible for all of the code that my app uses, not just the stuff I wrote — every single line of it. This means that bugs and security holes are my responsibility. How often do we see a WordPress or Drupal plugin get abandoned after a year or so? Am I sure I want to use a piece of code I don’t really understand, when a year down the road I may have to fix an exploit in it?
This is not to say that I would never use code that I didn’t write — I’d be hard-pressed to get much done that way, and frankly there are better programmers out there than me — but every line of code in my app matters, so I need to justify each one.
Create and use simple, readable code
I want code that is easy to understand. Understanding things quickly means getting stuff done faster. My time to productivity is shortened. My time to fix bugs is shortened.
I also want code that is easy to verify. My code should be testable, whether or not I get around to actually writing those tests, and I’ve consistently found that simpler, more modular code is more testable.
Readability should be a feature. Code should be simple and terse, but clear. Value clarity over cleverness. When I’m writing code, I try to consider how quickly another developer will be able to understand it at first glance. Alternately, will I be able to understand it when I come back to it in two months? The less time I waste trying to figure out how things work, the more there will be for getting things done.
I’d be lying if I said I always follow these principles. Sometimes, I just get lazy. Sometimes, time constraints mean I write hacky, complex code as fast as possible to get something working, or I pull in a library without reviewing it carefully, and hope it works. In the short term, writing simple, clear code is harder — it requires more discipline and frequent reassessment of technique. Particularly with time-sensitive projects, it’s hard to ever feel like I ever am entirely happy with the results.
But, when I make the time and put the effort in, it always pays off down the road — not just for myself, but for the other members of my team and people who use the code I’ve written, and that’s a really good feeling.
More Code, More Problems
Bài viết có 1 số phần chưa được dịch, 1 phần do kiến thức của mình chưa đủ, mình sẽ bổ sung sau.
Contents
Giới thiệu
Các phiên bản của UML
Giới thiệu
The Unified Modeling Language™ (UML®) is a standard visual modeling language intended to be used for
UML là 1 ngôn ngữ mô hình hóa chuẩn được sử dụng với mục đích :
- modeling business and similar processes,
- mô hình hóa quá trình kinh doanh và tương tự vậy.
- analysis, design, and implementation of software-based systems
- phân tích, thiết kế, và thực thi hệ thống phần mềm.
UML is a common language for business analysts, software architects and developers used to describe, specify, design, and document existing or new business processes, structure and behavior of artifacts of software systems.
UML là 1 ngôn ngữ thông dụng phục vụ phân tích kiến trúc kinh doanh, phần mềm và các nhà phát triển thường sử dụng nó để mô tả, đặc tả, thiết kế và viết tài liệu về các quá trình kinh doanh, cấu trúc và hành vi theo như tưởng tượng của các hệ thống phần mềm
UML can be applied to diverse application domains (e.g., banking, finance, internet, aerospace, healthcare, etc.) It can be used with all major object and component software development methods and for various implementation platforms (e.g., J2EE, .NET).
UML is a standard modeling language, not a software development process. UML 1.4.2 specification explains that process:
UML có thể được ứng dụng trong nhiều lĩnh vực khác nhau. Nó có thể được sử dụng với tất cả các quy trình phát triển phần mềm hướng thành phần và hướng đối tượng chính và cho 1 vài nền tảng thực thi ( như J2EE, .Net ). UML là 1 ngôn ngữ mô hình hóa chuẩn, không phải là 1 quá trình phát triển phần mềm. Quy định của UML 1.4.2 giải thích nhiệm vụ của UML như sau :
- provides guidance as to the order of a team’s activities,
- cung cấp chỉ dẫn trình tự hoạt động cho 1 đội,
- specifies what artifacts should be developed,
- đặc tả những gì cần phát triển,
- directs the tasks of individual developers and the team as a whole, and
- chỉ dẫn nhiệm vụ cho các nhà phát triển và đội của họ sao cho thống nhất, và
- offers criteria for monitoring and measuring a project’s products and activities.
- cung cấp các tiêu chuẩn cho việc theo dõi, đánh giá sản phẩm và hoạt động của 1 dự án.
UML is intentionally process independent and could be applied in the context of different processes. Still, it is most suitable for use case driven, iterative and incremental development processes. An example of such process is Rational Unified Process (RUP).
UML có chủ đích không phụ thuộc công nghệ và có thể ứng dụng trong hoàn cảnh của nhiều công nghệ khác nhau. UML rất phù hợp cho việc xử lý các use case, các quá trình phát triển lặp và tăng trưởng. Ví dụ như Rational Unified Process ( RUP ).
UML is not complete and it is not completely visual. Given some UML diagram, we can't be sure to understand depicted part or behavior of the system from the diagram alone. Some information could be intentionally omitted from the diagram, some information represented on the diagram could have different interpretations, and some concepts of UML have no graphical notation at all, so there is no way to depict those on diagrams.
UML không đầy đủ và nó không trực quan hoàn toàn. Với 1 số biểu đồ UML, chúng ta không thể chắc là sẽ hiểu hoàn toàn các phần được biểu diễn bằng mô hình hoặc hành vi của hệ thống chỉ từ các biểu đồ. Một số thông tin có thể bị lược bỏ khỏi biểu đồ 1 cách cố ý, 1 vài thông tin được miêu tả trên biểu đồ có thể có nhiều cách diễn giải khác nhau, và 1 số khái niệm của UML chưa có kí hiệu đồ họa, vậy nên chưa có cách nào để biểu diễn chúng trên biểu đồ.
For example, semantics of multiplicity of actors and multiplicity of use cases on use case diagrams is not defined precisely in the UML specification and could mean either concurrent or successive usage of use cases.
Ví dụ, ý nghĩa của tính đa dạng của các tác nhân và tính đa dạng của các use case trên biểu đồ use case chưa được khai báo 1 cách chính xác trong quy định của UML và nó còn có thể có nghĩa là sử dụng liên tiếp hoặc đồng thời các use case.
Name of an abstract classifier is shown in italics while final classifier has no specific graphical notation, so there is no way to determine whether classifier is final or not from the diagram.
Các phiên bản của UML
Phiên bản hiện tại của UML là UML 2.4.1, được phát hành tháng 8-2011. Phiên bản UML đầu tiên được tạo bởi 3 người bạn của nhau - Grady Booch (creator of Booch method), Ivar Jacobson (Object-Oriented Software Engineering, OOSE), and Jim Rumbaugh (Object-Modeling Technique, OMT). Quy định của UML ( chuẩn ) được cấp nhật và quản lý bởi Object Management Group (OMG™) OMG UML.
Version | Date | Description |
1.1 | 11-1997 | UML 1.1 proposal is adopted by the OMG. Đề xuất UML 1.1 được thông qua bởi OMG. |
1.3 | 03-2000 | Contains a number of changes to the UML metamodel, semantics, and notation, but should be considered a minor upgrade to the original proposal. Chứa 1 số thay đổi về metamodel ( thuộc tính trừu tượng, nổi bật của mô hình ), ngữ nghĩa và kí hiệu UML. Tuy nhiên nó chỉ được xem như 1 bản nâng cấp nhỏ so với phiên bản trước. |
1.4 | 09-2001 | Mostly "tuning" release but not completely upward compatible with the UML 1.3. Addition of profiles as UML extensions grouped together. Updated visibility of features. Stick arrowhead in interaction diagrams now denotes asynchronous call. Model element may now have multiple stereotypes. Clarified collaborations. Refined definitions of components and related concepts. Artifact was added to represent physical representations of components. |
1.5 | 03-2003 | Added actions (see Part 5 of spec) - executable actions and procedures, including their run-time semantics, defined the concept of a data flow to carry data between actions, etc. |
1.4.2 | 01-2005 | This version was accepted as ISO specification (standard) ISO/IEC 19501. UML 1.5 was released 2 years before. |
2.0 | 08-2005 | New diagrams: object diagrams, package diagrams, composite structure diagrams, interaction overview diagrams, timing diagrams, profile diagrams. Collaboration diagrams were renamed to communication diagrams. Activity diagrams and sequence diagrams were enhanced. Activities were redesigned to use a Petri-like semantics. Edges can now be contained in partitions. Partitions can be hierarchical and multidimensional. Explicitly modeled object flows are new. Classes have been extended with internal structures and ports (composite structures). Information flows were added. A collaboration now is a kind of classifier, and can have any kind of behavioral descriptions associated. Interactions are now contained within classifiers and not only within collaborations. It is now possible for use cases to be owned by classifiers in general and not just packages. New notation for concurrency and branching using combined fragments. Notation and/or semantics were updated for components, realization, deployments of artifacts. Components can no longer be directly deployed to nodes. Artifacts should be deployed instead. Implementation has been replaced by «manifest». Artifacts can now manifest any packageable element (not just components, as before). It is now possible to deploy to nodes with an internal structure. New metaclasses were added: connector, collaboration use, connector end, device, deployment specification, execution environment, accept event action, send object action, structural feature action, value pin, activity final, central buffer node, data stores, flow final, interruptible regions, loop nodes, parameter, port, behavior, behaviored classifier, duration, interval, time constraint, combined fragment, creation event, destruction event, execution event, interaction fragment, interaction use, receive signal event, send signal event, extension, etc. Many stereotypes were eliminated from the Standard UML Profile, e.g. «destroy», «facade», «friend», «profile», «requirement», «table», «thread». Integration between structural and behavioral models was improved with better support for executable models. |
2.1 | 04-2006 | Minor revision to UML 2.0 - corrections and consistency improvements. |
2.1.1 | 02-2007 | Minor revision to the UML 2.1 |
2.1.2 | 11-2007 | Minor revision to the UML 2.1.1 |
2.2 | 02-2009 | Fixed numerous minor consistency problems and added clarifications to UML 2.1.2 |
2.3 | 05-2010 | Minor revision to the UML 2.2, clarified associations and association classes, added final classifier, updated component diagrams, composite structures, actions, etc. |
2.4.1 | 08-2011 | Current version of UML, a minor revision to the UML 2.3, with few fixes and updates to classes, packages - added URI package attribute; updated actions; removed creation event, execution event, send and receive operation events, send and receive signal events, renamed destruction event to destruction occurrence specification; profiles - changed stereotypes and applied stereotypes to have upper-case first letter - «Metaclass» and stereotype application. |
2.5 FTF – Beta 1 | 11-2012 | Work in progress, in its finalization phase. From the UML language perspective, it will be a minor revision to the UML 2.4.1, while they spent a lot of efforts reorganizing specification document. It seems that this time professors took over researchers and industry practitioners, and instead of fixing actual UML issues they re-written UML specification to make it easier to read. For example, they tried to reduce forward references as much as possible which is an obvious requirement for textbooks but not for specifications. There will be no separate UML 2.5 Infrastructure document, so that the UML 2.5 specification will be a single document. Package merge will no longer be used within the specification itself. Four UML compliance levels (L0, L1, L2, and L3) are to be eliminated, as they were not useful in practice. UML 2.5 tools will have to support complete UML specification. Information flows, models, and templates will no longer be auxiliary UML constructs. At the same time, use cases, deployments, and the information flows to become UML supplementary concepts! |
UML Giới thiệu
On a rainy morning I found myself sitting on the desk thinking about efficient working. Before I started as a freelancer I had some days were I worked lots but could look only back on a worse outcome.
I started with Zen practice back in 2006. What clearly came to my mind before a good while was: the old Zenmasters already knew before hundreds of years, how today programmers should work. Even when I don’t like these “be a better programmer” posts, I want to outline some of my thoughts from that morning. It shall serve me as a reminder, but if you have some ideas about it, feel free to comment.
1. Focus
If you have decided to work on a task, do it as well as you can. Don’t start multiple things at the same time. Do only one thing at one time. You’ll not become quicker, just you work multi-threaded. If you work multi-threaded you’ll become exhausted, make more errors and lose time to jump from one task to another. This is not only about programming, this is a general tip.
Kodo Sawaki says: if you need to sleep, sleep. Don’t plan your software when you try to sleep. Just sleep. If you code, code. Don’t dream away – code. If you are so tired that you cannot program, sleep. Even known multitaskers like Stephan Uhrenbacher meanwhile have decided to work singlethreaded. I have made a similar experience to Stephan and finally I wrote Time & Bill, a time tracking tool. Goal was to track my time so easily that I even do it for small tasks like a phone call. Now I can create a few stopwatches at the beginning of the day and track my time with only one click. The outcome was a disaster: sometimes I just worked a few minutes on a task until I moved on to the next one. Now I am better. Similar to the Pomodoro technique I plan a few time slots and concentrate on them. No chatting, no sleeping, no checking out of a new great game on the Appstore.
2. Keep your mind clean
Before you work on your software, you need to clean up your memory. Throw away everything in your mind for the time being. If you have trouble with something, don’t let it influence you. It is mostly the case that trouble will go away. If the trouble is so heavy that you can’t let it go, don’t work. Try to clear things up. But when you start working, let the outer world shape away.
Something exciting on the mailing list? Leave it there. You can follow the exciting stuff again – later. Shutdown what fills your mind with shit: close Twitter, Facebook, your E-Mails. You should even mute the ringing of you mobile and leave it in your pocket. You can say it is similar to item #1, focus. But there is one more restriction: don’t use that tools before work or at lunch. They connect you with the outer world and probably bring up some new trouble or things which require you attention.
Think like this: at most times your mind is pretty clean when you wake up at the morning. If it is not, some sports helps (I do long distance running). If you feel clean and refreshed, go to work and work as well as you can. When you leave your work then you can fill up your mind with clutter. You’ll see it is not so much fun if you have a full working day behind you. Twitter and Co are consuming much of your energy. Do not think: it is just a minute. It is not.
You know it already.
3. Beginners mind.
Remember the days were you were a beginner. Or memorize, if you still are one. You have never learned enough. Think of yourself as you were a beginner, every day. Always try to see technologies from a beginners mind. You can accept corrections to your software better and leave the standard path if you need it more easily. There are some good ideas even from people who don’t have your experience.
Was there ever a software build twice, the same way? Even if you copy software it is somehow different.
4. No Ego.
Some programmers have a huge problem: their own ego. But there is no time for developing an ego. There is no time for being a rock star.
Who is it who decides about your quality as programmer? You? No. The others? Probably. But can you really compare an Apple with a Banana? No. You are an individual. You cannot compare your whole self with another human being. You can only compare a few facets.
A facet is nothing what you can be proud of. You are good at Java? Cool. The other guy is not as good as you, but better with bowling. Is Java more important than bowling? It depends on the situation. Probably you earn more money with Java, but the other guy might have more fun in life because of his bowling friends.
Can you really be proud because you are a geek? Programmers with ego don’t learn. Learn from everybody, from the experienced and from the noobs at the same time.
Kodo Sawaki once said: you are not important.
Think about it.
5. There is no career goal.
If you want to gain something and don’t care about your life “now”, you have already lost the game. Just act as well as you can, without looking at the goal you might reach after a long time.
Working for 20 years to become a partner? Why aren’t you working as hard as possible just because it is fun? Hard working can be fun. A day without work is a day without food is a Zen saying.
There is no need to start happiness after 20 years. You can be happy right now, even when you are not a Partner or don’t drive a Porsche. Things change too easily. You can get sick. You can get fired. You can burn out (if you follow all these items I guess likeliness is low).
Until these bad things happen, just work as well as you can and have fun with doing it. No reason to look at the gains of the colleges. No reason to think about the cool new position which you didn’t get.
After all, you will reach something. You’ll end up with nice memories, maybe a good position – and 20 excellent years. Every day is a good day.
If you ever come to the point were you think that working at your company is no fun at all you must leave immediately. NEVER stay at a company which does take away the happiness in your live. Of course, this is only possible in the rich countries, were people have the choice to go away. But if you are living in such an good environment, do it. Go away without regret. You have no time to waste, you are probably dead tomorrow.
When you have no career goal going away is easy.
6. Shut up.
If you don’t have anything to say, don’t waste the time of your colleagues. This doesn’t make you look wimpy. Everyday you work you need to try not getting on someones else nerves. Imagine if everybody would try this – what a great working place would that be? Sometimes it is not possible. Try hard, you will like it.
If you don’t develop an ego it is pretty easy to shut up and care on the things you have something to tell. Don mix up your ego with your “experience” and always remember: you are a beginner. If somebody has a good idea, support the idea.
7. Mindfulness. Care. Awareness.
Yes you are working. But at the same time you are living and breathing. Even when you have some hard times at work you need to listen to the signs of your body. You need to learn about the things which are good for you. This includes everything, including basic things like food. You need to care for yourself and for everything in your environment – because after all, the water you drink is the water which runs in the river. Because you are living only for yourself. You live alone and you’ll die alone. World goes on, even without you.
Avoid working situations you don’t like. Avoid working for free if it means you will have no fun and keeps you away from your bed. Let go what doesn’t make you happy. Working for free sounds is just theory? Consider the people doing Open Source in their prime time. If you have subscribed to some projects mailing list you probably know what heat there is (sometimes). If you don’t have fun with that – stop doing it. I know a bunch of people who work in an Open Source environment they don’t like. Again with Time & Bill I have tracked the time I spend in 0pen Source projects and was surprised how much time I lose there – esp. on projects I didn’t like so much.
Having this in mind, some people think they are only happy when they have prime time and can spend the evening with an xbox and some beer. While this is a good idea from time to time, it is not necessary that the whole time in your life is “fun”. If you can avoid situations you don’t like, avoid them (like I said above). But sometimes there is need to something really shitty. Like for example manually copy/pasting stuff from your managers Excel sheet into phpmyadmin. This can take you days, and it is really boring. It is no fun, but sometimes you need to do such stuff. You cannot always quit your job when you got a boring task. Zen Monks are not to shy with their work too. They get up at 4am (sometimes earlier, sometimes later, depends on the convent) and start meditation and work (they even consider work meditation practice). They have stuff to do like cleaning the toilets. Or working in the garden. Or as a Tenzo, they cook. They do it with all the care they can get. Whatever they do, they do it without suffering and they are (or should be) happy, because every second, even the second where they are cleaning toilets, is a second of their life.
That being said: stop crying, if you need to copy/paste excel. Just do it. Don’t waste your energy with such things, they will pass. Become the best excel copy/paster out there instead.
If you suffer a heart attack, people will probably say: “uh yes, he really worked too much, he even worked for me for free at night”. Nobody can guide you to the other world. This last step is taken by us alone. You cannot exchange anything in this world. Not even a fart. So it is up to you to take care, in every second. If you die, you die. But when you live you live. There is no time to waste.
“Care” is a huge word in zen buddhism (and I think in every form of buddhism). I cannot express everything which needs to be said. it is difficult to understand the different meanings of “care”. Probably you are better with the word “awareness”. You must be aware of what you do, in every second of your life. You must be mindful in your life. Otherwise you waste it. But, of course, it is up to you to do so, if you like.
8. There is no Boss
Yes, there is somebody who pays you. There is somebody who tells you what needs to be done. And he can fire you. But this is no reason to give up your own life or to become sick of your work. Finally your Boss has no control about you. It can even be doubted that you have control about you – but don’t lets go down this path.
Back to your Boss: he can make your life worse if you allow him to do so. But there is a way out. Say “No” if you need to do something which makes you sick or is against your ethics. What will happen? In worst case he will fire you. So what? If you live in western nations and if you are a coder (which is very likely when you read this) you’ll get another job.
I don’t mean to say “No” to tasks like copying CSV Data to HTML. I am speaking of 80 hours weeks and you feel your body breaks. Or if you feel that your kids could need some attention too. Or if you are forced to fire people just because your Boss doesn’t like them. Or if you are a consultant and get the job to develop software for nuclear plants (some might say it is perfectly fine to work for nuclear power companies – it is against my ethics and serves as an example) or for tanks. You can say “No”.
9. Do something else
A programmer is more than a programmer. You should do something which has nothing to do with computers. In your primetime, go sailing, fishing, diving. Do meditation, martial arts or play Shakuhachi. Whatever you do, do it with all the power you have (left). Like you do at your worktime. Do it seriously. A hobby is not just a hobby, it’s expression of who you are. Don let anybody fool you, when he says hobbies are not important. Nowadays we can effort having hobbies. I have recorded several CDs and wrote fantasy books (the latter one unpublished, I must practice more). These things have made me to the person I am now, and finally they have led me to Zen and this blog post. These days I practice Zen Shakuhachi. It is a very important aspect to my daily life.
10. There is nothing special.
A flower is beauty. But it’s just a beauty flower – nothing more. There is nothing special around it. You are a human who can program. Maybe you are good. There is nothing special around you. You are of the same kind as I am or all the others on this planet.
You need to go in the loo and you need to eat. Of course you need to sleep. After (hopefully) a long time you will die and everything you have created will be lost. Even pyramids get lost, after a long time. Do you know the names of the people who build up a pyramid? And if you do, is it important that you know? It’s not. Pyramids are there, or not. Nothing special.
Same goes to your software. The bank is earning money with your software. After you leave, nobody remembers you. There is nothing wrong around it. It is the flow of time. Nothing you should be worried about it. If you are living after the first 9 rules, you’ll see that this last project was a good and funny project. Now it’s simply time to go on and concentrate on something else.
If your comapany closes because of financial problems, no problem. Live will go on. There is no real need for a xbox, a car or something else. Most people on this planet live in deepest poorness. They don’t care on a xbox, because they would be glad to get some food or even water.
So… why exactly are you special? Because you had the luck to be born in the western territory? Because you can code? No, there is nothing special around it. You can let go you ego and live freely. Enjoy the colors and the smell of flowers around. Don’t be too sad when the winter comes and don’t be too happy when spring comes back. It is just a flow. Keep it in mind when somebody denies your application. Because the company is not so special that you need to be worried about the job.
Disclaimer
I am not a Zen monk. I am just practicing and learning. Please ask your local Zen monk if you feel there is something you need to understand deeper. Of course I can try to answer on this blog, but well, I am just a beginner. Anyway I am glad about your comment and if you would send a tweet with this pages url if you liked this post. Thanks for reading!
You want a book on Zen Programming? Click here.
Reference: The 10 rules of a Zen programmer from our JCG partner Christian Grobmeier at the PHP und Java Entwickler blog.
I started with Zen practice back in 2006. What clearly came to my mind before a good while was: the old Zenmasters already knew before hundreds of years, how today programmers should work. Even when I don’t like these “be a better programmer” posts, I want to outline some of my thoughts from that morning. It shall serve me as a reminder, but if you have some ideas about it, feel free to comment.
1. Focus
If you have decided to work on a task, do it as well as you can. Don’t start multiple things at the same time. Do only one thing at one time. You’ll not become quicker, just you work multi-threaded. If you work multi-threaded you’ll become exhausted, make more errors and lose time to jump from one task to another. This is not only about programming, this is a general tip.
Kodo Sawaki says: if you need to sleep, sleep. Don’t plan your software when you try to sleep. Just sleep. If you code, code. Don’t dream away – code. If you are so tired that you cannot program, sleep. Even known multitaskers like Stephan Uhrenbacher meanwhile have decided to work singlethreaded. I have made a similar experience to Stephan and finally I wrote Time & Bill, a time tracking tool. Goal was to track my time so easily that I even do it for small tasks like a phone call. Now I can create a few stopwatches at the beginning of the day and track my time with only one click. The outcome was a disaster: sometimes I just worked a few minutes on a task until I moved on to the next one. Now I am better. Similar to the Pomodoro technique I plan a few time slots and concentrate on them. No chatting, no sleeping, no checking out of a new great game on the Appstore.
2. Keep your mind clean
Before you work on your software, you need to clean up your memory. Throw away everything in your mind for the time being. If you have trouble with something, don’t let it influence you. It is mostly the case that trouble will go away. If the trouble is so heavy that you can’t let it go, don’t work. Try to clear things up. But when you start working, let the outer world shape away.
Something exciting on the mailing list? Leave it there. You can follow the exciting stuff again – later. Shutdown what fills your mind with shit: close Twitter, Facebook, your E-Mails. You should even mute the ringing of you mobile and leave it in your pocket. You can say it is similar to item #1, focus. But there is one more restriction: don’t use that tools before work or at lunch. They connect you with the outer world and probably bring up some new trouble or things which require you attention.
Think like this: at most times your mind is pretty clean when you wake up at the morning. If it is not, some sports helps (I do long distance running). If you feel clean and refreshed, go to work and work as well as you can. When you leave your work then you can fill up your mind with clutter. You’ll see it is not so much fun if you have a full working day behind you. Twitter and Co are consuming much of your energy. Do not think: it is just a minute. It is not.
You know it already.
3. Beginners mind.
Remember the days were you were a beginner. Or memorize, if you still are one. You have never learned enough. Think of yourself as you were a beginner, every day. Always try to see technologies from a beginners mind. You can accept corrections to your software better and leave the standard path if you need it more easily. There are some good ideas even from people who don’t have your experience.
Was there ever a software build twice, the same way? Even if you copy software it is somehow different.
4. No Ego.
Some programmers have a huge problem: their own ego. But there is no time for developing an ego. There is no time for being a rock star.
Who is it who decides about your quality as programmer? You? No. The others? Probably. But can you really compare an Apple with a Banana? No. You are an individual. You cannot compare your whole self with another human being. You can only compare a few facets.
A facet is nothing what you can be proud of. You are good at Java? Cool. The other guy is not as good as you, but better with bowling. Is Java more important than bowling? It depends on the situation. Probably you earn more money with Java, but the other guy might have more fun in life because of his bowling friends.
Can you really be proud because you are a geek? Programmers with ego don’t learn. Learn from everybody, from the experienced and from the noobs at the same time.
Kodo Sawaki once said: you are not important.
Think about it.
5. There is no career goal.
If you want to gain something and don’t care about your life “now”, you have already lost the game. Just act as well as you can, without looking at the goal you might reach after a long time.
Working for 20 years to become a partner? Why aren’t you working as hard as possible just because it is fun? Hard working can be fun. A day without work is a day without food is a Zen saying.
There is no need to start happiness after 20 years. You can be happy right now, even when you are not a Partner or don’t drive a Porsche. Things change too easily. You can get sick. You can get fired. You can burn out (if you follow all these items I guess likeliness is low).
Until these bad things happen, just work as well as you can and have fun with doing it. No reason to look at the gains of the colleges. No reason to think about the cool new position which you didn’t get.
After all, you will reach something. You’ll end up with nice memories, maybe a good position – and 20 excellent years. Every day is a good day.
If you ever come to the point were you think that working at your company is no fun at all you must leave immediately. NEVER stay at a company which does take away the happiness in your live. Of course, this is only possible in the rich countries, were people have the choice to go away. But if you are living in such an good environment, do it. Go away without regret. You have no time to waste, you are probably dead tomorrow.
When you have no career goal going away is easy.
6. Shut up.
If you don’t have anything to say, don’t waste the time of your colleagues. This doesn’t make you look wimpy. Everyday you work you need to try not getting on someones else nerves. Imagine if everybody would try this – what a great working place would that be? Sometimes it is not possible. Try hard, you will like it.
If you don’t develop an ego it is pretty easy to shut up and care on the things you have something to tell. Don mix up your ego with your “experience” and always remember: you are a beginner. If somebody has a good idea, support the idea.
7. Mindfulness. Care. Awareness.
Yes you are working. But at the same time you are living and breathing. Even when you have some hard times at work you need to listen to the signs of your body. You need to learn about the things which are good for you. This includes everything, including basic things like food. You need to care for yourself and for everything in your environment – because after all, the water you drink is the water which runs in the river. Because you are living only for yourself. You live alone and you’ll die alone. World goes on, even without you.
Avoid working situations you don’t like. Avoid working for free if it means you will have no fun and keeps you away from your bed. Let go what doesn’t make you happy. Working for free sounds is just theory? Consider the people doing Open Source in their prime time. If you have subscribed to some projects mailing list you probably know what heat there is (sometimes). If you don’t have fun with that – stop doing it. I know a bunch of people who work in an Open Source environment they don’t like. Again with Time & Bill I have tracked the time I spend in 0pen Source projects and was surprised how much time I lose there – esp. on projects I didn’t like so much.
Having this in mind, some people think they are only happy when they have prime time and can spend the evening with an xbox and some beer. While this is a good idea from time to time, it is not necessary that the whole time in your life is “fun”. If you can avoid situations you don’t like, avoid them (like I said above). But sometimes there is need to something really shitty. Like for example manually copy/pasting stuff from your managers Excel sheet into phpmyadmin. This can take you days, and it is really boring. It is no fun, but sometimes you need to do such stuff. You cannot always quit your job when you got a boring task. Zen Monks are not to shy with their work too. They get up at 4am (sometimes earlier, sometimes later, depends on the convent) and start meditation and work (they even consider work meditation practice). They have stuff to do like cleaning the toilets. Or working in the garden. Or as a Tenzo, they cook. They do it with all the care they can get. Whatever they do, they do it without suffering and they are (or should be) happy, because every second, even the second where they are cleaning toilets, is a second of their life.
That being said: stop crying, if you need to copy/paste excel. Just do it. Don’t waste your energy with such things, they will pass. Become the best excel copy/paster out there instead.
If you suffer a heart attack, people will probably say: “uh yes, he really worked too much, he even worked for me for free at night”. Nobody can guide you to the other world. This last step is taken by us alone. You cannot exchange anything in this world. Not even a fart. So it is up to you to take care, in every second. If you die, you die. But when you live you live. There is no time to waste.
“Care” is a huge word in zen buddhism (and I think in every form of buddhism). I cannot express everything which needs to be said. it is difficult to understand the different meanings of “care”. Probably you are better with the word “awareness”. You must be aware of what you do, in every second of your life. You must be mindful in your life. Otherwise you waste it. But, of course, it is up to you to do so, if you like.
8. There is no Boss
Yes, there is somebody who pays you. There is somebody who tells you what needs to be done. And he can fire you. But this is no reason to give up your own life or to become sick of your work. Finally your Boss has no control about you. It can even be doubted that you have control about you – but don’t lets go down this path.
Back to your Boss: he can make your life worse if you allow him to do so. But there is a way out. Say “No” if you need to do something which makes you sick or is against your ethics. What will happen? In worst case he will fire you. So what? If you live in western nations and if you are a coder (which is very likely when you read this) you’ll get another job.
I don’t mean to say “No” to tasks like copying CSV Data to HTML. I am speaking of 80 hours weeks and you feel your body breaks. Or if you feel that your kids could need some attention too. Or if you are forced to fire people just because your Boss doesn’t like them. Or if you are a consultant and get the job to develop software for nuclear plants (some might say it is perfectly fine to work for nuclear power companies – it is against my ethics and serves as an example) or for tanks. You can say “No”.
9. Do something else
A programmer is more than a programmer. You should do something which has nothing to do with computers. In your primetime, go sailing, fishing, diving. Do meditation, martial arts or play Shakuhachi. Whatever you do, do it with all the power you have (left). Like you do at your worktime. Do it seriously. A hobby is not just a hobby, it’s expression of who you are. Don let anybody fool you, when he says hobbies are not important. Nowadays we can effort having hobbies. I have recorded several CDs and wrote fantasy books (the latter one unpublished, I must practice more). These things have made me to the person I am now, and finally they have led me to Zen and this blog post. These days I practice Zen Shakuhachi. It is a very important aspect to my daily life.
10. There is nothing special.
A flower is beauty. But it’s just a beauty flower – nothing more. There is nothing special around it. You are a human who can program. Maybe you are good. There is nothing special around you. You are of the same kind as I am or all the others on this planet.
You need to go in the loo and you need to eat. Of course you need to sleep. After (hopefully) a long time you will die and everything you have created will be lost. Even pyramids get lost, after a long time. Do you know the names of the people who build up a pyramid? And if you do, is it important that you know? It’s not. Pyramids are there, or not. Nothing special.
Same goes to your software. The bank is earning money with your software. After you leave, nobody remembers you. There is nothing wrong around it. It is the flow of time. Nothing you should be worried about it. If you are living after the first 9 rules, you’ll see that this last project was a good and funny project. Now it’s simply time to go on and concentrate on something else.
If your comapany closes because of financial problems, no problem. Live will go on. There is no real need for a xbox, a car or something else. Most people on this planet live in deepest poorness. They don’t care on a xbox, because they would be glad to get some food or even water.
So… why exactly are you special? Because you had the luck to be born in the western territory? Because you can code? No, there is nothing special around it. You can let go you ego and live freely. Enjoy the colors and the smell of flowers around. Don’t be too sad when the winter comes and don’t be too happy when spring comes back. It is just a flow. Keep it in mind when somebody denies your application. Because the company is not so special that you need to be worried about the job.
Disclaimer
I am not a Zen monk. I am just practicing and learning. Please ask your local Zen monk if you feel there is something you need to understand deeper. Of course I can try to answer on this blog, but well, I am just a beginner. Anyway I am glad about your comment and if you would send a tweet with this pages url if you liked this post. Thanks for reading!
You want a book on Zen Programming? Click here.
Reference: The 10 rules of a Zen programmer from our JCG partner Christian Grobmeier at the PHP und Java Entwickler blog.
The 10 rules of a Zen programmer
Steve Jobs - Nhà sáng lập, cựu giám đốc điều hành thương hiệu nổi tiếng Apple. Một số ít người trên thế giới đã thay đổi cuộc sống của chúng ta từ cách giải trí, làm việc đến thói quen giao tiếp sinh hoạt hằng ngày, và Jobs là một trong số đó. Dưới sức ảnh hưởng rộng lớn của ông sau khi mất vào ngày 5/10/2011 do ung thư tuyến tiền liệt, cộng đồng mạng như Twitter đã lên tiếng rộng rãi cùng với hàng đoàn người tổ chức kỉ niệm trước các cửa hàng Apple Store.
Bộ Film 60" HDTV sẽ cho ta thấy lại những khoảnh khắc cuộc đời ấn tượng của ông.
Trong bộ Film này chúng ta không chỉ xem xét về tài năng, phong cách và trí tưởng tượng tuyệt vời của Jobs mà còn nhìn cách ông đã định hình và ảnh hưởng rộng rãi đến đời sống của chúng ta như thế nào. Ta sẽ phỏng vấn những người đã một thời và hiện vẫn từng hợp tác với Jobs, như Ronald Wayne - đồng sáng lập Apple Computer; Robert Palladino- nhà thư pháp với các lớp học mà Jobs thừa nhận tạo nên cảm hứng cho ông thiết kế kiểu chữ cho máy tính Mac; Dean Hovey - người thiết kế con chuột cho Aplle cùng nhiều người khác.v.v...
Video infomation
Container: Matroska
Runtime: 56mn 24s
Size: 1.56 GiB
Video
Codec: x264
Resolution: 1280x720
Aspect ratio: 16:9
Frame rate: 29.970 fps
Bit rate: 3 799 Kbps
Audio
English 5.1ch AAC
Fshare download link
http://www.fshare.vn/file/TF77799KYT
Vietnamese subtitle
http://subscene.com/vietnamese/Steve-Jobs-One-Last-Thing/subtitle-567900.aspx
