Tips From the Trenches

Discussions

Blogs: Tips From the Trenches

  1. Tips From the Trenches (2 messages)

    Though Tips from the Trenches by Matt Gullet is aimed at those of us that are alone in their development efforts, it contains a lot practical advice that works for those working in team environment. The article is divided into two sections, technical and non-technical aspects of Matt's job. Matt also describes what he has worked towards in his three years of going it alone. The list of non technical advice includes; * Set personal goals * Read, Read, Read * Come out of the closet * Meetings are not all bad, just mostly bad * After hours is off limits * Set reasonable expectations * I'm not a programmer, I'm an architect When setting a goal one must also set a dead line in which that goal should be reached
    One of the things I have learned about goals is that any real goal must have a deadline attached to it. You will notice that each of the goals I listed is singular in nature and has a set deadline
    Matt comments that setting deadlines helps him in managing his schedule. He also notes the difficulties of setting personal goals and comments how he manages to avoid setting himself up for failure. Matt doesn’t claim to meet all of his goals but he does try to understand what caused him to miss. This information is often useful when one sets new goals as it often addresses compromises and sacrifices that one is not willing to make. On the subject of meetings, the advice addresses how to measure the potential usefulness. The guidelines include the ability of the person calling the meeting to set an agenda, the length is relation to the topic, the number of and roles of the people invited. If Matt was aiming to avoid all useless meetings then he clearly has failed. Matt recognizes that there are meeting that just cannot be avoided. However these meeting still offer opportunities to improve communication skills. There is also an interesting aspect of putting in time after-hours.
    At one point, I found myself saying to myself (and others) that I would have a particular feature/component/whatever finished by Monday morning. This is a dead giveaway for a problem. How can anything be ready in the morning unless you plan to work on it at night?
    The technical aspects include; * Plan, then code * The right tool for the right job * Fix bugs early * Develop good coding habits * Know thy enemy * Documentation is your friend * Form over function In the category of know thy enemy, Matt points to two major devourers of time, procrastination and gold plating. The two main reasons for procrastination fear of failure and avoiding the mundane. Gold platting is always trying to work with latest and greatest technologies without understanding if there will be benefits to do so. The advice here is to limit gold platting till the end of the project. This limits the chance that you’ll over-run the schedule.

    Threaded Messages (2)

  2. Use paper first.[ Go to top ]

    It looks like the author has totaly revised his work and lots of things turned out to be wrong. This is good when one is not afraid to analyze his or her approaches if the latter exist at all. And better if one can look at an approach from a different angle and admit that an approach is wrong. I will explain. When I was a little kid and I attended some classes on information science where we solved problems and coded the algorithms. The teacher used to tell us that first you have to "write" your program on a sheet of paper and only then go to the computer and code it. This is absolutely true. Nowdays we have rich diagramming tools but sometimes they are too complicated for developers (even if you are not a starting developer). But this is not the reason to stop draw diagrams and write some text on paper. So I would advise that noone must be afraid or neglect plain old sheet of paper and a pen. Even if you do not know UML or any other notation for describing what you want to achieve think out your own! Just switch off your monitor and try to set everything out on paper. So returning to my first phrase about the approaches. Do not throw yourself to your computer instantly after getting a problem. Use paper first and let your brain start the flow instead of any other tool.
  3. Amazing article[ Go to top ]

    Loved every word of it. It took me a full hour to read it, simply because I gave it that time, because it makes ssoo much sense. Lots of it is common sense, a "learn from your mistakes" attitude - but, oh so important! I also have to agree with some of the comments left by Grigory (to this blog). He talks about the importance of putting down "code" on paper. I agree wholeheartedly. I hate diving into code on a screen and then keep back-tracking. I put down some logic (pseudo- and comment-code) on paper for a problem just yesterday and realized before I'd changed any source files why it was NOT going to work. Even helped when I had to explain that to my teammmate. Paper - and pencil - two best tools!