Curious about the Sara Has No Limits thing?

You may be wondering why I title my blog, “Sara Has No Limits”. One might guess that it has somethNoLimitsCovering to do with the limits that Salesforce imposes. Good guess, especially since I have now immersed myself into the world of Salesforce and Force.com development, but that actually has nothing to do with it.

You see, I have been an independent software developer since 2005, and in 2009, I wrote and self-published a small book about my experiences, titled, “No Limits: How I escaped the clutches of Corporate America to live the Self-employed life of my dreams” . I have to admit the book was wildly unpopular and I ended up giving away more copies than I ever sold. **sigh**

It’s okay though because I am still very proud of the book and glad that I wrote it. I learned about myself in the process and I know it touched a few people (so that is all that really matters anyway).

But, if you are curious about the book and would like to order a copy, I still have a bunch and I am obviously willing to sell them – at a very reduced price ($5.99). Basically, I am just asking you to cover the cost of shipping and a little for my time in going to the rural post office I live near to mail it to you. So, if you would like to read my spine tingling book AND you live in the United States, click the Buy Now button below.

btn_buynowCC_LG

Slide Deck from Dreamforce 14 Session

SlideDeckOn Tuesday I had the honor of speaking at a Dreamforce 14 session titled, “Career Strategies for Developers Transitioning to Salesforce”. A few people at the session asked whether my slide deck would be made available and I promised them I would post it on my blog, so that is the main purpose for this post. If you are interested in the slides from my session, you can find them here.

If you are interested in the other developers I interviewed to prepare for this session, then you can check them out here. I will be adding one each week.

And if you came by the session, THANKS!!!

Speaking at Dreamforce 2014

I am very excited to announce that I will be presenting a session at the 2014 Dreamforce Developer Track entitled, “Career DreamforceStrategies for Developers Transitioning to Salesforce“. The main goal for this session is to offer practical ways that experienced developers that are just new to Salesforce can transition their skills to the platform.

I would love to hear from any of you that may be facing this unique challenge – either to share with me your experiences or to just tell me what you would like to learn. Please feel free to contact me through this blog with ANY feedback you may have. All feedback is welcome as I want this to be coming from multiple perspectives. Just go to the About Sara page and submit the contact form and I promise to get back to you quickly.

I really think this a chance to talk openly about something that is not often spoken of and I hope to answer the following questions:

How do you successfully capitalize on your existing development skills when moving to a new platform such as Salesforce?

and

What resources can you access to help you make the most of your transition?

 

Career and Survival Strategies for Software Developers

QuestionsI just watched a Pluralsight course that I think EVERY software developer should watch. It is for developers brand new to the field, those that have been developing for only a few years, and those that have been developing for many years.

The course is general and non-technical, but is highly informative, extremely insightful, and remarkably hilarious.

The course is titled, “Career and Survival Strategies for Software Developers” by Dan Appleman. Dan talks honestly about the things that are important to every developer, but that are oddly hardly ever mentioned. Things like:

“How do I keep up with the latest technologies and not become obsolete?”

“How do I deal with all the professional politics that go along with being a developer?”

“How do I make the kind of money I need or want?”

So please take the time to watch this course and let me know what you think…

Back up your Phone Right NOW!!!!

Last Friday evening, I stopped at a local convenience store for just a few seconds. PhoneBackupTwenty minutes later, I reached towards my phone cradle to make a call and realized my phone was gone.

Stolen, you ask? It certainly appeared that way.

I acted quickly. I returned home and immediately called my carrier to report the phone as stolen. They issued a block that would prevent anyone from using the phone on another network.

The next day I called the carrier back to see what I could do to get a new phone. I was lost after all and was already feeling highly anxious. I am sure you would feel that way too.

The nice woman on the phone told me she could send another phone and then asked if I had a backup. I sheepishly replied, “No”. The shame is that I am a developer by profession. Of anyone out there, I should know better. Heck, I even spent two years working for a company whose main selling point was providing companies quality backups.

Yet here I was…up the proverbial creek – without a paddle, or a backup. Nope my last backup was done 6 months prior. 6 months! Outrageous!!!!

Now, fortunately this story does have a happy ending. 3  hours after I hung up the phone with my carrier, I returned to my car to clean it. Guess what? My phone was there. It had accidentally fallen out of the cradle and fell under the seat. It was there all the time. Never stolen. I was a VERY lucky girl.

I consider it all to be an omen and a reason for me to share this warning with others. Do not find yourself in the same unfortunate position. As technology professionals, we really should know better and we really should ensure that we do regular backups of our machines AND devices. Especially our devices. These days they tend to hold more valuable information than our computers.

So please, take the time to make that backup right now.

And also, don’t leave your phones in your car, even for a second.

Take Care,

Sara

Approved as a new Lynda.com Author

lynda_logo1k-d_72x72I just got word that I have been approved to be a new Lynda.com author! They want me to design a series of courses on Salesforce development. They currently have none, so this is very exciting. One of the things I really like about Lynda.com is their commitment to high-quality productions. They are leaders in the area of online video training.

The first course will likely be very introductory (such as “Up and Running with Visualforce Development”).  If you have suggestions for areas you think I should cover, I would love to hear from you. Feel free to comment to this post or to send me a message directly though my contact form.

I will be sure and announce when the course is approved and of course, when it is released. Until then, please send me your thoughts.

Why a .NET Developer Loves Force.com

When I graduated from College 20 years ago, I had no idea how much would change in the world of Software Development. Back then, the college I attended taught students COBOL as the primary language (and yes, I realize that some people reading this will not even know what that is).

It is lucky for me that I love learning new things. My entire career has been one VERY long lesson – one that changes on an almost daily basis. Blink and you’ll miss the next great language, platform or tool.

While learning new things never bothered me, the other day a simple exercise demonstrated to me how much of a hit my productivity has taken as a result of all the constant big changes in the .NET world of development.

I have been focused on .NET development ever since it emerged and before that, I was a big Visual Basic developer. A little over two years ago, I was introduced to the world of Force.com. One of my clients was using Salesforce and they needed to make it work well with the .NET-based Portal platform they were using.

Despite some initial hesitations, I found myself liking the platform more and more. I loved how stable it was and how I did not have to waste days tracking down crazy server configuration issues (like I did so often when deploying .NET applications). So over the past two years, I have spent as much time as possible learning all about it. A few months ago, I earned the Developer certification and I am currently studying for the advanced certification.

I really came to appreciate the platform when the other day I decided to use it to build a prototype application for a new client. The client was unsure about whether to go further with a project to replace their membership management system. In less than two days (10 hours total), I was able to put together a bare-bones membership management system using a free developer edition.

gbrarams

The prototype application (which has been intentionally blurred to hide sensitive data) included tabs for Documents, Reports, Dashboards, Chatter and Ideas, right off the bat. No programming required. Not a single line of code had to be written. All I did was use the declarative features of the platform to build the app and then I used the Apex Data Loader to import a large group of production member data into the new system. This really helped the client to see the potential of the platform.

I could have never put together something like this on the .NET platform so quickly. The reality is that it would have taken weeks to have put together a .NET prototype with the same amount of functionality. Now, do not get me wrong. I Still love .NET and I am not trying to put it down in any way. But, I have to be honest when I acknowledge that being a .NET developer these days can be a tad bit overwhelming. It seems like just when you have some new tool or language figured out, it has become obsolete and no one is using it any more.

I doubt I will ever get to the point where I am focused solely on any one platform (Force.com or .NET). I think the trick to being valuable as a developer is to keep an open mind and have as vast a skill set as possible. There is never one tool for every job in this business.

I would love to hear what you think???

Anatomy of a Great System Document and Why you should Bother

As a professional writer, I admit that I probably focus on documentation more than your average software developer. Over the years, I have learned quite a bit about what goes into making a GREAT system document. I have also noted the extreme lack of good quality system documentation at many of my client locations.

Unfortunately, next to initial design and testing, documentation probably comes in last as far as the amount of time allocated to it for development projects. I have met plenty of programmers who think that the only documentation they have to provide is the occasional comment in their code. By the time the project is over, very few people take the time to go back and create a proper system document.

What most novice programmers fail to realize is that good system documentation is not just a benefit for the client or even for other programmers. It is also not just for large or commercially-based projects. A system document should be created for any size software development project, whether that be for a commercial-based project or just a single-man project done in a small IT department.

Why Bother?

If done properly, a system document can serve many purposes – most of them benefiting the person that created the document. I have been creating system documents for all my software projects for the past 20 years and I have benefited in the following ways:

  • A GREAT system document serves as a calling card for you. It demonstrates that you are a quality worker and that you are attentive to detail. It also reminds people about the work you have done long after you have left a place. This is especially important for software consultants. I actually had a former boss recently contact me for a consulting job, all because he ran across a system document I produced 10 years ago.
  • You can refer to some of your best ones when trying to land a new job or consulting gig. Unless you work exclusively with public facing web sites, it is not always easy to provide a direct link to some of your past work.

    If you keep copies of all the system documents you have produced for employers or clients, you can use these as examples of your quality work. I can promise that offering or producing them for an employer WILL set you apart from the rest of the developers.

  • It can save you LOTS of time. I cannot tell you how many times I have gone back to reference system documentation I have wrote for one project when working on another. In many cases, the stuff I read (even just 6 months later) seems entirely brand new to me and is often very helpful in pointing me in the right direction for resolving a problem or coming up with a good idea.

What Should it Contain? SystemDocTemplate

After years of creating system documents, I have learned a thing or two about what works best. For example, simple and straight to the point language is the best. It should NOT read like a White Paper or some graduate student thesis. It should not even resemble professional software documentation.

If you are creating a system document for a project that involves using some other piece of software, do not include information that could be found in the manual for that software. For example, I created a system document for a large integration project that I worked on. The project involved using a software tool called Scribe to create data transformation scripts. Scribe already has extensive documentation that covers how to use that product. There was no need to include any of that. In fact, my document included a section that stated this fact and pointed the reader to where the online Scribe documentation was located.

The system document you create should contain the kind of information that is not obvious. Get to the point and stick to only including things that someone like you, someone who knows the project intimately would know. The exact length of the document will vary depending on the complexity of the project.

Your document should always include a Last Updated area in the header. This should include a date time that is updated automatically when the document is opened and saved.

As far as what sections to include, I suggest some of the following:

  • What is this about?
    This section is required and should be the first section in every system document you produce.  It should contain information about who originated the project and provide some reasoning for why it was done. The system may be multifaceted and involve multiple applications and scripts, so all of these pieces should be referenced in this section.
  • How do I use or access it?
    This should provide a basic overview of how to use or access the system. If the application is web-based, it should contain a link to it. If it is a desktop or console application, it should specify where the installation files are located. It should also include any special logins and passwords that may be needed.It should assume the reader knows nothing about the system and they are just getting started using it. Including screenshots of the application can be very helpful. This should not be as extensive as a complete user document, but it should at least get the reader logged in to the system and familiar with the basic layout.
  • How do I get started supporting or modifying it?
    This should contain information that a software developer would need to know to access the system as quickly as possible. If the system consists of more than one application, then it should contain links or paths to where the code is located for all applications. If working with the software involves installing any other special software, it should include information about that and what is needed.
  • What if it does not work right?
    Hopefully, the person creating this document has kept notes while working with the system and has undoubtedly encountered issues while testing and deploying. These notes will be helpful in building this section, which should be a bulleted listing of what these issues are and what can be done to resolve them. Remember, the reader of this document is someone who will be tasked with supporting the system and they will likely not be familiar with all the problems you faced creating the system.
  • What kind of changes will I need to make to the system?
    Ask yourself what kinds of changes will likely need to be made to the system and use this section to list those areas. For example, what if the system needs to be moved to different servers? What if the person supporting the application needs to change configuration or database settings?

When should it be created and how much time will it take?

Ideally, you should allocate time in every software project for creating system documentation. The amount of time you allocate is proportional to the size of the project and in my experience is usually about 10% of the total project time. So, if a project takes 100 man hours to design, code, test and deploy, 10 hours should be allocated to creating system documentation.

NOTE that this is separate from any user documentation that you may have to create. The time required to produce user documentation should be included in the total project time. The reader of the system document is someone who will be tasked with supporting or modifying the application. They are likely a software developer and you should assume that they are brand new to the organization.

I understand that creating system documentation like this is not something that comes natural to most developers. But, I can promise that the more you do it, the easier it gets. And, I can also promise you that if you take the time to do it right, you will thank yourself for doing it one day.

Clean Code: Writing Code for Humans

I am a proud monthly subscriber of the online training website Pluralsight. I cannot imagine staying up to date in this field without that subscription. Since my blog focuses on Salesforce concepts, I will tell you that Pluralsight offers several brilliant courses that cover Salesforce.

CleanCodeBut, this post is titled “Clean Code: Writing Code for Humans” by Cory House, a brand new course just offered on Pluralsight. The course is described as the following:

“Anyone can write code a computer can understand, but professional developers write code *humans* can understand. Clean code is a reader-focused development style that produces software that’s easy to write, read and maintain.”

If you are new to programming (of ANY language), then this course if for YOU!

Even if you are an experienced programmer (of ANY language), then this course is for YOU TOO!  I have been doing software programming for over 20 years and have regularly espoused many of the concepts covered in this class, and I learned plenty by watching it. We are ALL prone to writing dirty code and this course has great practical advice for how to avoid this.

If your goal is to remain a programmer (more specifically, a productive and respected programmer), then this course is definitely for YOU!!!!!

Even if you do not already have a subscription to Pluralsight, never fear, they offer a free 10-day trial subscription. So, you really have no excuse. Go and see it I tell you.