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.
Your Product Manager
Software development initiatives include a number of different types of meetings across the whole development process. The participants’ attitudes and cognitive process also play an important role in decision-making activities in these meetings. But are all the meetings productive? Don’t we really need to focus on the effectiveness of meetings?
1) Time is spent for the meeting before, during and after:
Most employees use up to four hours of their workweek just to prepare for their regular meetings. According to an Atlassian study, as many as 45 percent of employees felt overwhelmed because they were attending so many meetings in a short period of time. This can lead to additional stress that could be avoided if companies start requiring employees to attend only the most important meetings. That’s why some companies opt for cost effective meetings via platforms like Blue Jeans Network to check the cost associated with each meeting.
2) Brainstorming may not actually rain down ideas:
If management ask participants to brainstorm during the meeting, they may actually restrict the thinking process by trying to restrict the thinking in a timebox. Being forced to come up with creative solutions on the spot can be intimidating for your employees, according to Market Wired.
3) Lack of engagement during the meeting:
Most employees multitask during meetings, which shows lack of engagement in the meetings. Therefore meetings end up being less productive. Marie shared some statistics to support this:
At least 92 percent of employees are guilty of multitasking during a meeting, according to Fuse. At least 73 percent of people admit to doing tasks that are unrelated to work or the meeting they are in, states Atlassian
Marie said that this lack of engagement could happen because of long meeting durations.
There are some tools which anyone can use to calculate the cost of the meeting. These tools are helpful in finding out the effectiveness of meetings in terms of financial figures and help management in finding out ways to make meetings more fruitful in terms of time and money.
MeetingKing is a tool which calculates the cost of the meeting just by asking some basic information like number of participants, average salary of participants and duration of meeting. Research done my MeetingKing shows that if managers use meetings appropriately they can reduce the time spent by 25%.
Marie mentioned that we should try different tools to remain focused in meetings. Only having phone calls is not sufficient, if we can arrange video conferences then seeing each other’s body language, people will most likely pay more attention.
Meetings can be useful, but only if they are utilized properly. The first step in preventing unproductive meetings is identifying and admitting that these problems exist in the first place. Many of these problems can be resolved by setting clear expectations for each meeting.
Try alternatives, or better yet, see if you can do without a meeting at all. If meetings are held only for the most important topics, and involve only the most crucial key people who can actually do something about the problem at hand, then you will get more value for your company’s time and money.
source link: http://www.infoq.com/news/2014/10/effective-meetings
Most developers have the herd mentality–they stick with the herd and value themselves based on where they fit in it. At the front of the herd, you are doing good. At the back of the herd, you are in danger of becoming a hungry lion’s next meal.
Developers at the front make more money and have nicer offices, the ones at the back make less and live in tiny cubicles, but they are all part of the herd. So, even though there is a difference in pay from the junior developer to the senior one, there isn’t much of a difference in pay from one senior developer to another, even if one of the senior developers is more valuable and has more advanced skills.
As software developers, we are acutely aware of our position within the pecking order. We know which developers are higher up than us and which ones are lower. The titles at our jobs help us to know our place.
The rest of the world has no idea about which developers have greater skill and can do a better job, and for the most part, they don’t care—they just see a pack, with some developers at the front and other developers at the back. When an employer hires you for a job, they just want to know where you are in the pack. Are you at the front? The back? The middle? They pay you accordingly based on your ranking within the pack.
If you aren’t explicitly standing out far beyond the pack, you are going to be grouped right in with the pack and paid accordingly. And once you make it to the front of the pack, you’ve got nowhere to go in their eyes—you’re already the best.
This glass ceiling isn’t there because someone mandated that software developers shall only make so much money and live in 5 by 5 cubicles. The glass ceiling is there, because unless you are doing something extreme enough to differentiate yourself from the pack completely, you are part of the pack and the pack is always going to stick together. The average salary of software developers will be used to determine what developers at the front of the pack will be paid, as well as what the developers at the back of the pack will be paid.
This is, of course, easier said than done.There are a few developer animals out there who break away from the herd. They don’t waste their time competing for a position within the pack–they just outrun the pack completely. If you want to increase your value as a software developer, your goal should be to break away from the pack. How? Entrepreneurship, Working on Dream Project, joining the Industry Giant, Consultancy etc, This is something you have to decide by your own, how and when to break from pack is something you have to do it by your own.
But the key is learn to market yourself.