Talk:Good style in Lojban

From Lojban
Jump to navigation Jump to search
  1. Care About Your Craft
    Why spend your life developing software unless you care about doing it well?
  2. Think! About Your Work
    Turn off the autopilot and take control. Constantly critique and appraise your work.
  3. Be a Catalyst for Change
    You can't force change on people. Instead, show them how the future might be and help them participate in creating it.
  4. Make Quality a Requirements Issue
    Involve your users in determining the project's real quality requirements.
  5. Invest Regularly in Your Knowledge Portfolio
    Make learning a habit.
  6. Critically Analyze What You Read and Hear
    Don't be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.
  7. It's Both What You Say and the Way You Say It
    There's no point in having great ideas if you don't communicate them effectively.
  8. Eliminate Effects Between Unrelated Things
    Design components that are self-contained. independent, and have a single, well-defined purpose.
  9. Use Tracer Bullets to Find the Target
    Tracer bullets let you home in on your target by trying things and seeing how close they land.
  10. Prototype to Learn
    Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.
  11. Program Close to the Problem Domain
    Design and code in your user's language.
  12. Estimate to Avoid Surprises
    Estimate before you start. You'll spot potential problems up front.
  13. Iterate the Schedule with the Code
    Use experience you gain as you implement to refine the project time scales.
  14. Keep Knowledge in Plain Text
    Plain text won't become obsolete. It helps leverage your work and simplifies debugging and testing.
  15. Use the Power of Command Shells
    Use the shell when graphical user interfaces don't cut it.
  16. Always Use Source Code Control
    Source code control is a time machine for your work – you can go back.
  17. Fix the Problem, Not the Blame
    It doesn't really matter whether the bug is your fault or someone else's – it is still your problem, and it still needs to be fixed.
  18. Don't Panic When Debugging
    Take a deep breath and THINK! about what could be causing the bug.
  19. "select" Isn't Broken.
    It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.
  20. Don't Assume It – Prove It
    Prove your assumptions in the actual environment – with real data and boundary conditions.
  21. Learn a Text Manipulation Language.
    You spend a large part of each day working with text. Why not have the computer do some of it for you?
  22. Write Code That Writes Code
    Code generators increase your productivity and help avoid duplication.
  23. You Can't Write Perfect Software
    Software can't be perfect. Protect your code and users from the inevitable errors.
  24. Design with Contracts
    Use contracts to document and verify that code does no more and no less than it claims to do.
  25. Crash Early
    A dead program normally does a lot less damage than a crippled one.
  26. Use Assertions to Prevent the Impossible
    Assertions validate your assumptions. Use them to protect your code from an uncertain world.
  27. Use Exceptions for Exceptional Problems
    Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things.
  28. Finish What You Start
    Where possible, the routine or object that allocates a resource should be responsible for deallocating it.
  29. Minimize Coupling Between Modules
    Avoid coupling by writing "shy" code and applying the Law of Demeter.
  30. Configure, Don't Integrate
    Implement technology choices for an application as configuration options, not through integration or engineering.
  31. Put Abstractions in Code, Details in Metadata
    Program for the general case, and put the specifics outside the compiled code base.
  32. Analyze Workflow to Improve Concurrency
    Exploit concurrency in your user's workflow.
  33. Design Using Services
    Design in terms of services – independent, concurrent objects behind well-defined, consistent interfaces.
  34. Always Design for Concurrency
    Allow for concurrency, and you'll design cleaner interfaces with fewer assumptions.
  35. Separate Views from Models
    Gain flexibility at low cost by designing your application in terms of models and views.
  36. Use Blackboards to Coordinate Workflow
    Use blackboards to coordinate disparate facts and agents, while maintaining independence and isolation among participants.
  37. Don't Program by Coincidence
    Rely only on reliable things. Beware of accidental complexity, and don't confuse a happy coincidence with a purposeful plan.
  38. Estimate the Order of Your Algorithms
    Get a feel for how long things are likely to take before you write code.
  39. Test Your Estimates
    Mathematical analysis of algorithms doesn't tell you everything. Try timing your code in its target environment.
  40. Refactor Early, Refactor Often
    Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.
  41. Design to Test
    Start thinking about testing before you write a line of code.
  42. Test Your Software, or Your Users Will
    Test ruthlessly. Don't make your users find bugs for you.
  43. Don't Use Wizard Code You Don't Understand
    Wizards can generate reams of code. Make sure you understand all of it before you incorporate it into your project.
  44. Don't Gather Requirements – Dig for Them
    Requirements rarely lie on the surface. They're buried deep beneath layers of assumptions, misconceptions, and politics.
  45. Workwith a User to Think Like a User
    It's the best way to gain insight into how the system will really be used.
  46. Abstractions Live Longer than Details
    Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.
  47. Use a Project Glossary
    Create and maintain a single source of all the specific terms and vocabulary for a project.
  48. Don't Think Outside the Box – Find the Box
    When faced with an impossible problem, identify the real constraints. Ask yourself: "Does it have to be done this way? Does it have to be done at all?"
  49. Start When You're Ready.
    You've been building experience all your life. Don't ignore niggling doubts.
  50. Some Things Are Better Done than Described
    Don't fall into the specification spiral – at some point you need to start coding.
  51. Don't Be a Slave to Formal Methods.
    Don't blindly adopt any technique without putting it into the context of your development practices and capabilities.
  52. Costly Tools Don't Produce Better Designs
    Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.
  53. Organize Teams Around Functionality
    Don't separate designers from coders, testers from data modelers. Build teams the way you build code.
  54. Don't Use Manual Procedures
    A shell script or batch file will execute the same instructions, in the same order, time after time.
  55. Test Early. Test Often. Test Automatically
    Tests that run with every build are much more effective than test plans that sit on a shelf.
  56. Use Saboteurs to Test Your Testing
    Introduce bugs on purpose in a separate copy of the source to verify that testing will catch them.
  57. Test State Coverage, Not Code Coverage
    Identify and test significant program states. Just testing lines of code isn't enough.
  58. Find Bugs Once
    Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.
  59. English is Just a Programming Language
    Write documents as you would write code: honor the DRY principle, use metadata, MVC, automatic generation, and so on.
  60. Build Documentation In, Don't Bolt It On
    Documentation created separately from code is less likely to be correct and up to date.
  61. Gently Exceed Your Users' Expectations
    Come to understand your users' expectations, then deliver just that little bit more.
  62. Sign Your Work
    Craftsmen of an earlier age were proud to sign their work. You should be, too.
  63. Languages To Learn
    Tired of C, C++, and Java? Try CLOS, Dylan, Eiffel, Objective C, Prolog, Smalltalk, or TOM. Each of these languages has different capabilities and a different "flavor." Try a small project at home using one or more of them.
  64. The WISDOM Acrostic
    What do you want them to learn?
    • What is their interest in what you've got to say?
    • How sophisticated are they?
    • How much detail do they want?
    • Whom do you want to own the information?
    • How can you motivate them to listen to you?
  65. How to Maintain Orthogonality
    • Design independent, well-defined components.
    • Keep your code decoupled.
    • Avoid global data.
    • Refactor similar functions.
  66. Things to prototype
    • Architecture
    • New functionality in an existing system
    • Structure or contents of external data
    • Third-party tools or components
    • Performance issues
    • User interface design
  67. Architectural Questions
    • Are responsibilities well defined?
    • Are the collaborations well defined?
    • Is coupling minimized?
    • Can you identify potential duplication?
    • Are interface definitions and constraints acceptable?
    • Can modules access needed data – when needed?
  68. Debugging Checklist
    • Is the problem being reported a direct result of the underlying bug, or merely a symptom?
    • Is the bug really in the compiler? Is it in the OS? Or is it in your code?
    • If you explained this problem in detail to a coworker, what would you say?
    • If the suspect code passes its unit tests, are the tests complete enough? What happens if you run the unit test with this data?
    • Do the conditions that caused this bug exist anywhere else in the system?
  69. Law of Demeter for Functions
    An object's method should call only methods belonging to:
    • Itself
    • Any parameters passed in
    • Objects it creates
    • Component objects
  70. How to Program Deliberately
    • Stay aware of what you're doing.
    • Don't code blindfolded.
    • Proceed from a plan.
    • Rely only on reliable things.
    • Document your assumptions.
    • Test assumptions as well as code.
    • Prioritize your effort.
    • Don't be a slave to history.
  71. When to Refactor
    • You discover a violation of the DRY principle.
    • You find things that could be more orthogonal.
    • Your knowledge improves.
    • The requirements evolve.
    • You need to improve performance.
  72. Cutting the Gordian Knot
    When solving impossible problems, ask yourself:
    • Is there an easier way?
    • Am I solving the right problem?
    • Why is this a problem?
    • What makes it hard?
    • Do I have to do it this way?
    • Does it have to be done at all?
  73. Aspects of Testing
    • Unit testing
    • Integration testing
    • Validation and verification
    • Resource exhaustion, errors, and recovery
    • Performance testing
    • Usability testing
    • Testing the tests themselves
  74. 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 multithreaded. If you work multithreaded 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 phonecall. 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.
  75. 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 mailinglist? 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.
  76. 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.
  77. 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 rockstar. 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 facettes. 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.
  78. 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 to 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 collegs. 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 life. 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 a 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.
  79. 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 someone's 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't mix up your ego with your "experience" and always remember: you are a beginner. If somebody has a good idea, support the idea.
  80. 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" is just theory? Consider the people doing Open Source in their prime time. If you have subscribed to some projects mailinglist 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 Open 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. Whatevery 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". Propably 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.
  81. 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 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".
  82. 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.
  83. 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 company closes because of financial problems, no problem. Life will go on. There is no real need for an xbox, a car or something else. Most people on this planet live in deepest poorness. They don't care about an 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 about 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.

Learning Lojban

  1. Get real. Decide on a simple, attainable goal to start with so that you don't feel overwhelmed.
Pick up 50 words of Lojban and start using them on people — and then slowly start picking up grammar.


  1. Make language-learning a lifestyle change. Elisabeth Buffard, who in her 27 years of teaching English has always seen consistency as what separates the most successful students from the rest. Find a language habit that you can follow even when you're tired, sick or madly in love.
  2. Play house with the language. The more you invite Lojban into your daily life, the more your brain will consider it something useful and worth caring about. Use every opportunity to get exposed to Lojban. Label every object in your house in this language, read stories written in Simple Lojban, utter live-narrate parts of your day to an imaginary Lojban friend.
  3. Let technology help you out. Dmitrochenkova has a great idea: “A funny thing like resetting the language on your phone can help you learn new words right away,” she says. Ditto for changing the language on your browser. Or you can seek out more structured learning opportunities online. Dutch translator Els De Keyserrecommends Duolinguo for its gamified approach to grammar, and Anki for memorizing vocabulary with its “intelligent” flashcards.
  4. Think about language-learning as a gateway to new experiences. To Spanish translator Sebastián Betti, learning a language has always been about focusing on the experiences that the new language would open up, from “visiting theme parks, attending air shows, enjoying cowboy poetry and folk-rock festivals, to learning about photo-essay techniques.” In other words, he thinks of fun things that he wanted to do anyway, and makes them into a language-learning opportunity. Many of our translators shared this advice. Italian and French translator Anna Minolilearned English by watching undubbed versions of her favorite movies, while Croatian translator Ivan Stamenković suddenly realized he could speak English in fifth grade, after years of watching the Cartoon Network without subtitles. So the next time you need a vegan carrot cake recipe, find one in the language you're trying to learn.
  5. Make new friends. Interacting in the new language is key — it will teach you to intuitively express your thoughts, instead of mentally translating each sentence before you say it. Find native speakers near you. Or search for foreign penpals or set up a language tandem online, where two volunteers help one another practice their respective languages.
  6. Do not worry about making mistakes. One of the most common barriers to conversing in a new language is the fear of making mistakes. But native speakers are like doting parents: any attempt from you to communicate in their language is objective proof that you are a gifted genius. They'll appreciate your effort and even help you. Nervous about holding a conversation with a peer? Try testing your language skills with someone a little younger. “I was stoked when I was chatting with an Italian toddler and realized we had the same level of Italian,” recalls German translator Judith Matz. And be patient. The more you speak, the closer you'll get to the elusive ideal of “native-like fluency.” And to talking to people your own age.

If .... then

  1. Whenever a Lojbanist writes a new paragraph that appears to be parsable, it always means that there are problems either with the scope or with the meaning of individual words.
  2. When a Lojbanist receives no complaints about their texts it means that no one read it.
  3. The more accurately the author applies suggestions from other Lojbanists, the more silly the text becomes.
  4. The more listeners understand Lojban, the more they prevent continuation of a fluent conversation.
  5. Mistakes are easier to make and harder to discover in the most simple parts of the text.
  6. The most durable parts of Lojban are patches made ad hoc and in haste.
  7. The more a Lojbanist complains about others' texts the less frequently he makes his own.
  8. The more versatile is a text, the less places there are where one could apply it.
  9. The grammar of Lojban is easy. It's like asking "what is round and ripe and has an apple seed inside?