Dear Software Engineers, your job is not to write code!

Dear Software Engineers,

Your job is not to write code.

I know. You think you were hired to write code. In fact, your entire interview process centered around how well you could write code. And I’m sure you do it really well.

But it’s not your job.

Your job is to improve our product for our users. If you want to get technical about it, your job is to improve our product for our users in a way that improves the key metrics of the company. But honestly, you don’t always have a lot of control over that second bit. You do, however, have an enormous amount of control over the first bit!

Of course, if you want to do your job well, it does mean that you may have to change some of your current behaviors.

For one thing, you need to make sure that the code you write (writing code is still one of the main things you will do when doing your job, by the way) runs the way it should, even on users’ machines.

Did you know that our users probably don’t have brand new MacBook Airs with giant Thunderbolt monitors set at the highest resolution possible and running the latest version of Chrome? I checked. A lot of them have Internet Explorer on 4 year old laptops, so sometimes things you build don’t work right on their machines. They’re still our users, and it’s still your job to improve the product for them, so please make sure that the code you wrote works in a reasonable number of environments.

In fact, you’re going to need to make sure that the code you wrote runs in production, in general. I don’t really care if your code runs locally. If your code just runs locally, then my only option is to sell your computer so that our users can use our software, and that really doesn’t scale.

So, to avoid that, you need to check your changes in production. Every time. Remember, your job is not just to ship something. It’s to ship something that improves our product for our customers. You can’t know it will do that unless you check that it runs in the way it’s supposed to.

Of course, in order to check your changes in production, you’re going to need to make sure that your code actually gets merged and pushed into production. I mean, you can’t really check your changes in production if you just let them sit unpushed for hours or days. Push your code. Get it into production. Then run it and check it.

This is obviously harder to do if you’re in an environment where you can’t do continuous deployment, but the theory still holds. When your code gets into production, whenever that is, you’re still responsible for it. Make sure that it’s doing what it ought to be doing – which is make the product better for users.

Another thing to remember is that sometimes users do surprising things, which means that it’s not enough just to test that your code works under perfect conditions. You need to make sure that it does something reasonable even in error cases and zero data states and when the user does something you might not expect, like use the back button or make two accounts by mistake.

This is hard. It means you’ll have to spend time thinking about the different things our users might do. But it’s an important part of your job, because it will vastly improve the product for our users if they aren’t constantly finding bugs or edge cases or dead ends.

There’s one more important part to your job. You need to make sure that we can measure whether we’re all doing our jobs well. That means adding metrics and analytics so that we can test the effects of our changes. If you expect the code you are writing to improve user engagement (by improving the user experience in some key way), then you need to have a way to learn whether or not you succeeded. How else will you know if your job is done? Because, as I’ve mentioned, your job isn’t done until you’ve improved the product for our users.

I know what you’re thinking. This will all take so long! I’ll be so much less effective!

This isn’t true. You’ll be far more effective because you will actually be doing your job. If you get hassled for writing less code, that’s a failure of management, and I apologize for it. We need to spend less time demanding that you write features and more time asking you to improve our product for our users. If we’re not doing that, I strongly suggest you ask us to. If we still refuse, you should leave and find an environment that lets you do your job. Which, not to beat a dead horse, is to make the product better for our users.

Please don’t feel like I’m picking on you. You’re not the only one who should be doing this job. It is all of our jobs to make the product better for our users. It is my job as a PM and UX Designer and Manager to understand our users well enough that I can help you know how to improve the product for them. It is the CEO’s job to find a strategy that allows us to make money by improving the product for our users.

No matter what our job titles, our jobs are all the same — to make the product better for our users. Every day. So let’s do that.

Thank you,

Your Product Manager

Dear Engineers, your job is not to write code! – Tweet This

*This post originally appeared on Medium*

Advertisements

LinkedIn Recommendation template

Most of us have worked with great colleagues, bosses, and employees over the years who we’d be happy to recommend on LinkedIn (or anywhere, really) in a heartbeat if asked.

Problem is, of course, that sitting down and writing said recommendation always takes more time than you think it will. What should you say that will make your contact stand out—but still sound genuine? Should you describe every amazing skill this person has—or keep it short and sweet?

Don’t worry. We’ve turned that daunting task into a five-step (and five-minute) process. Next time you’re asked to recommend someone, follow this template (complete with sample lines to cut and paste—we won’t tell!).

Step 1: Start With a Knockout Line

As with any good writing, you want to start with a line that grabs your audience and makes them want to read more. (After all, what good is a great recommendation if no one reads all the way through?)

Ideally, this line will show right away what an awesome person your recommendee is. Be careful, though, to avoid phrases like “one of the best” or “one of my favorite employees”—while, no, not everyone’s going to be the ultimate superlative, there are plenty of words and phrases that sound just as strong, but less qualified.

It’s rare that you come across standout talent like Mike.”

Few people have the opportunity to report to a manager who is also a coach and mentor—but I did when I worked for Susan.”

‘Ridiculously efficient’ is the phrase that comes to mind when I think about Tim.”

 

Step 2: Describe Your Relationship

Next, you’ll want to give the reader some context as to how you know the person, including your reporting relationship, what you worked on together, and the length of time you’ve known each other. While you don’t have to give all the details (LinkedIn will show the company and both of your job titles on your recommendation), it’s important to let readers know why you’re qualified to give the recommendation. (And, of course, be sure to note that it was a positive working relationship!)

I had the pleasure of working with Jim for two years at the Smith Company, collaborating on several project teams.”

I hired Carrie as a freelance designer in 2011 after seeing her online portfolio, and she’s completed six flawless projects for me since then.”

Mark expertly filled the role of social media coordinator for my company’s marketing team for just over a year.”

 

Step 3: Share a Standout Trait

If you’re recommending someone, there’s a good chance you think he or she is smart, talented, organized, wonderful to work with, the list goes on. So, there’s no need to use the limited characters in your recommendation to state the obvious.

Instead, think about one or two things this person does better than anything else—or that really stand out to you above others—and focus your recommendation there. You can also ask the person if there’s something he or she would like you to talk about: For example, if she was your executive assistant but is now applying to her first management role, she’ll likely want you to highlight her experience managing volunteers over her organizational skills.

I was particularly impressed by Kelly’s ability to handle even the toughest clients—and effortlessly. That skill often takes years to develop among customer service professionals, but it seemed to come perfectly naturally to her.”

I was always in awe of Fred’s ability to command a room and get people on board with ideas—even people who were initially on completely different pages.”

Matt’s ability to juggle multiple projects was unlike any I’ve seen before and made a dramatic difference in the productivity level of our team.”

 

Step 4: Add a Touch of Personality

Let’s face it: Everyone wants to hire someone who not only gets the job done, but who’s also great to work with. So, if you can share a tidbit about what it’s like to work with this person or some insight into his or her personality, do so! (Just, you know, know your audience. “Sophie planned the best office happy hours ever!” might not go over so well with her future employers.)

Oh, and she made sure our Monday morning staff meetings were never without bagels and coffee. Talk about motivating a team!”

And we still miss her on the office softball league!”

No matter how tense a meeting, Annie made sure everyone left with a smile.”

 

Step 5: End With Your Solid Recommendation

Finally, it’s always nice to seal your recommendation with a final line that makes it clear that you give your contact an enthusiastic thumbs-up. You don’t need to do much here—think short, sweet, and solid.

Allison would be an asset to any team.”

As a team member or a leader, Steve earns my highest recommendation.”

Any employee would be lucky to have Michelle as a manager.”

Try It!

While we recommend following the steps above to create a new recommendation for each contact, here’s a quick example of how to put them all together (and a template to use if you’re pressed for time!).

[Descriptive phrase] is the phrase that comes to mind when I think about [name]. I’ve had the pleasure of knowing [name] for[length of time], during which [description of your working relationship]. Above all, I was impressed with [name]’s ability to[description of what makes person really stand out]. And, of course, his/her [personality trait]. [Name] would be a true asset for any positions requiring [1-2 skills needed for position] and comes with my heartfelt recommendation.

That’s it—five steps, five lines, and five minutes to a recommendation that will make sure your contact shines.

Best Practice – Leave the ego behind, Be eager to learn

We always learn from books and now a days from internet. But IT is such a field where we learn a lot from our colleagues. They are our best references, but there are software developers who either feel shy in asking their doubts or if they will ask then they are not thankful to others so ultimately when they ask next time they get zero answer.

IT is vast and nobody can have complete knowledge on any subject. Every day we come across different problems. So Ask…Don’t feel shy if you don’t know X.

I’m not suggesting you to bother someone unreasonably and asking for spoon feeding to learn anything. NO, be polite, thankful, to the point, understanding and supporting to others.

New technologies are coming everyday

If you want to sustain in the market then you would have to keep yourself updated with latest IT tools, and technologies. Following are the few sources

  • Technical Forums over the internet.

  • Technical magazines on various IT subjects.

  • Technical Bulletin Boards

  • Conferences, Trainings and workshops

  • Latest versions of old tools and packages, languages etc.

Best Practice- Keep your Commands, Tools & Techniques Handy

You might be require to test your application url time and again, now typing it every time or searching it time and again might lead to time loss and may result in incorrect urls as well. Here the best practice it to bookmark the application url in the bookmark toolbar and use it.

There are lot of common tasks like stopping the server, redeploying etc. instead of running the commands you can write all of these in a script and keep that script handy to run.

The database url, port, credentials and other important stuff, which are generally required at the time of setup, but if not kept safely, will eat up a lot of time when required again. so keep them safe as well.

Best Practice – Keep your Code and Documents Safely

Multiple copies create confusion

This is true that having backup is one of the most important best practices but it should be maintained in well managed way like you can use tags like name, date and time of the backup, version etc. otherwise if you have multiple copies of the same source code or document, then it will create confusion and it would be difficult to identify latest code or document.

When taking a local backup, if you do not give a proper name or strategy, you end up updating a different file and wonder that why it is not getting reflected in your application isn’t funny. At times older files overrides the latest code and causes trouble. So make a strategy or standard and follow it religiously.

This is strongly recommended to use proper source code version control system. There are many source code version control software freely available like (SCCS, CVS, Subversion etc.) which you can use to store different versions of the software. But while using a source code control system then following the following rule:

  • Always take source code form the controlling system.

  • Assign a new version to every change.

  • Always put source code back into controlling system.

Best Practice – Testing to be followed like a religion.

Testing is mandatory after every small or big change no matter how tight schedule you have or you just changed a small comment inside the code, you have testing due for the changed code.

There is nothing like trust while developing software, no matter how expert or how senior you are in writing source code, you would have to perform testing for each and every change you did in the code.

  • Tight schedule, no compromise.

  • Changed just a comment, still you have to test it.

  • Changed just a variable name, testing has to be done.

  • If you feel lazy…it’s too dangerous.

Don’t want to follow it? You will be in trouble!

software_testing

Celebrate every bug you find

Yes you should not feel unhappy if you or another tester finds a bug in your software source code. Following are the enough reasons to celebrate this discovery:

  • Bugs are your enemies, so you have killed one.

  • Now your software is having one bug less.

  • Mistakes are good as long as they are not repeating.

  • What you learn today, it prepares you for tomorrow

Best Practice – Code should be written to be reviewed.

While writing your software code, keep in mind that someone is going to review your code and you will have to face criticism about one or more of the following points but not limited to:

  • Bad coding

  • Not following standard

  • Not keeping performance in mind

  • History, Indentation, Comments are not appropriate.

  • Readability is poor

  • Open files are not closed

  • Allocated memory has not been released

  • Too many global variables.

  • Too much hard coding.

  • Poor error handling.

  • No modularity.

  • Repeated code.

Keep all the above mentioned points in your mind while coding and stop them before they jump in your source code. Once you are done with your coding, go for a self review atleast once. I’m sure, a self review would help you in removing 90% problems yourself.

Once you are completely done with your coding and self review, request your peer for a code review. I would strongly recommend to accept review comments happily and should be thankful to your code reviewers about the comments. Same time it is never good to criticize any source code written by someone else. If you never did it, try it once and check the coder’s expression.

Accept criticism but don’t criticize

Poorly written source code teaches you to write good source code provided you take it positively and learn a lesson from it.

bug_free

Your target should be to stop the bugs at first place and create a BUG FREE code. Think like a tester so that you should have a challenge for the testers.