There was a Twitter interaction about testers being invited or not to team meetings and about providing value to the team.
And it got me thinking.
Articles
I’ve seen a number of individuals make transitions to new careers through all walks of life. Heck, I’ve seen English and History majors excel at IT consulting and end up being great senior IT executives!
It can be done just like Ray Kroc started McDonald’s in his early 50s. Nothing is ever too late.
I used to write software for a living. I did that for a lot of years, as a matter of fact. And, in doing so, I learned a lot about how to write software.
But I learned this from the perspective of, well, a wage software developer. Today, I’d like to reflect on how my view has evolved over the last number of years.
Employers and recruiters spend on average 7 seconds reading a resume so if you don’t immediately capture and retain their attention; your resume is going straight in the reject pile. As a Resume Writer, I have noticed these two common mistakes made in my Software Developer clients’ resumes. Take note of my advice and watch the interview invites come rolling in.
Your Resume Isn’t Tailored to Every Job You Apply To
A common mistake made by my clients is that they use the same resume to apply to multiple jobs. You should have a different resume for every job you apply to. Job adverts posted by employers and recruiters differ so why would you use the same resume to apply for each job? Your resume needs to closely match employers’ requirements.
Not too long after I started my career, in the 1990s, I found myself on the other side of the interview table. Part of my responsibilities were to evaluate and interview candidates for the summer internships. This was quite an interesting challenge for me, since I was sitting on the other side of the interview table just months before I was given the task.
Over the last twenty-seven years, I have been involved with the new hire process — scanning through piles of resumes, interviewing candidates and even making the decision on who to hire and to not hire for a given position. During this time, I have built my own top-ten list of things to keep in mind when submitting your credentials for an open opportunity.
I am sure you have heard that software developers are lazy. They don’t do much most of the time and only actually work a couple of hours over the day.
When you are in an assembly plant, for example, assembling televisions, it’s an issue in that type of work if someone stops doing his task for just a couple of minutes. Those couple of minutes will mean that fewer televisions will be produced and when we convert that to money, it will raise the cost of the product.
This is a very frequent request that we come across.
“I have been a software developer for quite some time and would like to learn about a new role. I am excited about a business analysis career, but I have no idea as to how to transition into the new role. “
Last month, we were very fortunate to have André Meyer come into Tasktop to give a presentation on fostering software developer productivity. For many years André has been working with a research team with one of our company co-founders, Gail Murphy, to address the ongoing supply and demand shortage in software delivery.
As "software continues to eat the world," the need for software is outstripping our ability to supply it. Just how do we enable and empower software developers to build better software faster and make them more productive?
Before explaining a sprint retrospective, I am assuming that you have a fairly good knowledge of Agile practice management. This blog doesn’t cover Agile basics. This blog is for anyone who wants to be successful in running an Agile Retrospective.
The sprint retrospective is just for Scrum teams and gives the team an opportunity at the end of the sprint to take a look back at the sprint that just ended, which may be one or two weeks depending on your sprint length and determine, what went well, what problem areas that may have had and how they can improve upon those areas as they move forward to the next sprint.
Introduction
Do you love your job? I am sure that you have thought of this question before, or perhaps someone might have asked you this question. I agree that it is a simple question, and it has simple words in it. But were you able to answer that? If you have never tried to answer that, please try now. If you have a satisfying answer within you, then that is amazing. Unfortunately, if you can’t answer that positively or are uncertain, please read this post.
Background
If you want to see some tips to become a successful software engineer, I strongly recommend that you read my post here. Until now, I’ve worked with many companies, including startups and multinational companies. After joining a company, I asked this question “Do I love this job?”, “Is it what I am capable of?”, and “Is this work challenging me?” Sometimes, the answer to these questions came in the form of my resignations. In this 7-year span, I have learned a few things, and I am happy to share that information with you all. You can always see the articles related to career advice here.
