David Sparks @macsparky and Katie Floyd @katiefloyd in their MacPowerUsers 37 podcast talked about Markdown and MultiMarkdown. I actually used Markdown - see John Gruber’s Daring Fireball Markdown Syntax - in a project at work in which I had to generate documentation formatted as docbook. Fortunately there was a Markdown to docbook translator called Pandoc and it performed (almost) flawlessly - I had to add in a small macro in (ugh) UltraEdit to clean up the generated documentation so the Eclipse postprocessor would be happy with it.
This led me to recall a chapter I had read in Jon Bentley’s highly recommended programming book “More Programming Pearls: Confessions of a Coder” (ISBN 0-201-11889-0). Jon talks about what he calls “little languages” in Column 9, in which he describes a language as ‘any mechanism to express intent’ - thus the linkage to Markdown. Notations or languages such as LaTex, TROFF, and Markdown are akin to other “programming” languages such as C and FORTRAN in that they instruct the computer to process input and generate output. It’s just that these little languages hide a huge amount of complexity in their brevity and let us get on with the things we want to do instead of worrying about the actual syntax of the final output (docbook XML, HTML, instructions to a typesetting system…)
Agree or NO? "Interestingly with the influx of developers moving into OO coding there seems to be a revival of software principles"
Agree wholeheartedly! Here are some considerations:
- OO coding brings in rigour in coding practices - leading to implicit adoption of good coding methodology.
- Starting on learning something different and new, such as OO methodologies, may lead to developer to explore and learn good software principles, especially when OO methodologies are closely associated with software principles.
- OO practitioners are by and large well founded in software principles - so a developer moving to the OO coding methodology would be motivated to adopt good software principles.
Here’s what I mused over...
Leadership by virtue of its general appellation, means to me to inspire, motivate and direct a group. Technical expertise is only a small fraction of the role. Inspiration lets you lead by example, the way you solve problems, write code, hold conversations, run meetings and even handle your e-mail (yup, welcome to the Inbox Zero crowd!). Your team members and peers will certainly take notice and perhaps begin to emulate. It’s a tough job - you have to be on your toes to make sure that you’re being a good role model and that any detractions are noted and rectified - it’s the way to get better. Inspire - lead by example.
Motivation is a little different, to me, than inspiration - it’s when you have to get your team going as a focussed entity to solve a problem. Communication is key here - making sure that everyone knows what is required of them and of the team as a whole.
Direct - this is where you have to set goals and determine actions to be performed to achieve those goals. Milestones, project and resource management come into play here.
One of the nice things about working in a large corporation is that you get to attend really interesting courses. The recent Personal Leadership course I took changed my skeptical outlook on the value of these courses. Sure there were the usual (maybe trite at times) team building and icebreaker exercises but the key takeaways from the course were often intangible - networking, collaboration and communication. I wound up being introspective into my role in the group and charted a plan of action to improve. The 270º survey (self, bosses and peers) was extremely helpful - letting me know my strengths and where I needed to improve.