Just a short post about an old lesson that I was reminded of today.

I've done a few projects for some financial institutions that include date sensitive operations and calculations, things that have to be aware of the current date and will change values depending on what the date is, or processes that need to execute in a certain order and need to be completed all within the same day, etc.

One of the key things we realized early on is that we would need to build these calculations (and to some extent the processes) so that:

• The calculations had the flexibility to be executed "out of time" ie. you had the ability to simulate what the current date/date time was so you could get the results out of the calculations that you wanted.
• The system had built-in time-senstive reminders to prompt users to take certain actions and not forget.

In the former, this was important for a few reasons:

I write a lot of code comments. It helps me structure my code and make it a bit easier to scan, but it helps my future self too: understand why I did something; alerts for pitfalls or not so obvious code structures; etc.  I've also written apologies to other developers who may come across my code one day. :P

Something that I've started doing in the past year is "tagging" my code: adding hashtags to act as bookmarks to help me find key lines of code that are related to something I'm working on or something I did in the past.

Some examples:

// #tags #kludge #revisit

...or...

// #tags #2015rebuild #govLimits

They always start with "#tags" so I can find all the tags later (doing a search inside project files) and remind myself of what keywords I used, and then follow up with something more descriptive about whatever I'm tagging.

Since the new year I've been doing some research about what's being going on in the front-end dev world in the last few years since I've been away from it.  The times, they are a changing, and they are a changing rapidly!  I've pulled together a link dump of a bunch of articles that I found really interesting on a range of topics, you may find some of this useful and insightful...

I was watching this talk on how to go from being an intermediate developer to a expert programmer, and ended up pulling out this great nugget from a gentleman named Ed Weissman:

A smart accountant once told me that the answer to “How much money did you make?” is always, “Who wants to know?” If it’s an investor, the answer is “A lot.” If it’s a customer, the answer is “A little.” If it’s the IRS, the answer is “None.”

Same thing here. The answer to “Who is a good programmer?” is always, “Who wants to know?”

To a project manager, the programmer who hits every deadline (regardless of quality) is a good programmer.

To a customer, the programmer who solves their problem quickest is a good programmer.

To a business owner, the programmer who makes them the most money is a good programmer.

As designers/developers, I think we're incredibly uneasy with saying "I don't know".  In a knowledge-based economy/industry, your knowledge is your currency, so I think there's pressure to appear like you know everything. A combination of being used to presenting a good front to the clients, looking up to rock stars in our industry who can "do it all", and general pride perhaps.  The industry also changes so fast, new standards, new technologies, and there's always a fear of falling behind the curve.

I think that's a lot of weight to be carrying around, and we don't always realize it's there.

I've been in enough meetings to know that not everybody knows how to run them. (or at least how I think they should be run ;)  Meetings are important, especially face to face, in order to define actions or gather requirements, build consensus in order to make decisions, keep people updated on where things are at, make sure the project is running smoothly and on time, catch problems before they're catastrophes, etc.  Unlike some people, I don't think meetings are evil, but I do think that they can be misused and be unproductive when not run correctly.

Here's some things I try to keep in mind:

I recently had to do some research for a collegue who had some questions about "clickjacking", the practice of hosting a website inside a hidden or transparent iframe (the target), positioning that frame over top of another inocuous, innocent looking page (the attacker) that has a call to action.  The user clicks what they think is something simple (like a video play button) but instead they're clicking on a page element inside the transparent iframe, initiating some action on the target website.

For example, an attacking website could get a user to login to their banking website without them knowing, depending on whether the user had configured their browser to autofill in their username and password on the site.  The attacking site could go on to do lots of other things, tricking the user into transfering money or whatever.

Scary stuff.

Over the years I've earned a reputation as a ferverent, unrepentent note taker.  I write notes about everything, scribbling stuff in an artist's sketch pad, typing madly in a text file or more recently thumbing myself reminders into my iOS-device.  In meetings I'm constantly writing things down, summarizing discussions, making note of key points.

I'm not sure what it is, maybe it's because I don't trust my brain to remember, or maybe because it *helps* me remember or it's because I'm detail oriented.  I do know that it helps me accurately hold the entire architecture of whatever it is I'm working on in my head, which makes it a lot easier to make informed decisions and weigh the implications of choices later on.

I thought I'd share a few tips 'n tricks about how I take notes, maybe you'll find something useful...

So I've been working with Salesforce for about a year now, as a developer and consultant, and something I've been running into a lot lately is code rot: code that lives tucked away somewhere and never gets updated 'cuz it's working and it was made by someone who's no longer in the picture and nobody knows what it does. Or code that has ceased to be relevant or used for months/years, but no one's stopped to go in and remove it. Or that thing that happens when you have a whole bunch of different people doing work on your SF org, and they're all from different companies and have different standards and levels of skill and so on, and nobody wants to take the responsibility of updating or fixing somebody else's current or old code.

UPDATE: In Spring '12, Role Hierarchies were added to the MetaData API, so you can use changesets or your IDE of choice to migrate role hierarchy changes.  No need for this whole mess!!!  Stop reading!! :)