Support NeoGAF

[0xCA2]

After a couple internships and part-time jobs, I'm thinking maybe programming as a career isn't for me.

*I'm a very detail oriented thinker, I have to see implementation level details first before I understand the big picture. Unfortunately, I often can't see the field for the trees. As someone who's working primarily on web dev/ application dev projects, this causes a lot of problems for me, because:

- I often focus on implementation level details that don't matter.
- I have trouble communicating with team members about big picture concepts. Often info-dump implementation details that they don't care about while missing 'the point'. Often can't process 'the point' without understanding implementation details.
- The code that I write is often very self contained and doesn't interface with the overarching system well at all
- My solutions technically solve the problems I'm given but aren't necesarily best for the goals of the project
- Have a hard time writing architecture unless I've already finished the implementation, at which point its probably too late
- Often slower because of all of the above

This detail oriented thinking is a problem I have in life and it isn't something that I can do much to change*. I've already seen coworkers who just 'get it' leaving me in the dust.

What should I do here? Should I just quit the field? Are there any books or resources that can help? Are there any specific programming jobs that benefit from this kind of thinking? I'm thinking maybe IT would be better for me.

I'm graduating in December and I really want to be sure this is the right field for me before diving in head first.

*

Spoiler

Because I'm on the spectrum...

 

[kadotsu]

Maybe you should start to do test driven development. That way you think about how other people will use the code you write.

 

[Zoe]

QA may be a better path.

 

[HarryHengst]

QA/testing might be a good choice. You can still use your programming skills, but its a field that especially benefits from having a hyperfocus on specific issues and details.

 

[Window]

This isn't something unique to computer science. Most if not all professional roles require dealing with incomplete information in limited time frames in a collaborative environment, communicating with people across various levels and business functions. What you're experiencing is quite normal for someone relatively new to the workforce but you will get better with practice. So don't worry about it and do what you enjoy

 

[lucebuce12]

QA may be a better path.

QA/testing might be a good choice. You can still use your programming skills, but its a field that especially benefits from having a hyperfocus on specific issues and details.

This!

Go with what your strengths are, and your strengths seem perfect for QA as long as your programming skills are sharp.

 

[BlackGoku03]

Takes time and experience. Had you not gone through this, you wouldn't know where to improve. But no matter where you go, most managers don't like to hear the how, they like to hear "It's done, and on time".

And depending on the environment, coders tend to not see the big picture anyway. Some places like to review code structure instead of reviewing features or fixing large issues.

Depends on where you want to go and work. You sound young; these things take time.


Coding is too much for me. I'll stick with batch scripts, excel formulas, and powershell scripts. Those are hard enough.

 

[SlimySnake]

Yeah, once you get a real job, you will be pressed for time all the time. sounds like you are a bit OCD and in a field where you are in crunch 365 days a year, you cannot be that guy asking for specs and wasting everyone's time instead of just figuring shit out on your own.

To be fair, no matter what field you go in, they will expect you to 'get it', figure stuff out on your own instead of spoon feeding you everything. if this sounds harsh then you are in for a rude awakening when you are in the thick of it and having to answer why you couldnt get shit done in the allotted time.

QA might be better suited for you since they have to think of the details and check things programmers usually wouldnt. that said, if you are going to be one of those QA engineers who want a test plan and specs with everything you are going to have problems.

instead of reading books, i would recommend some therapy instead. sort out your ocd and while you may not be able to change your way of thinking, they might be able to help you work around it.

 

[Angelus Errare]

Pretty sure most of us post college are like this, then the field breaks you and forces you to abandon such an approach.

Maybe you should start to do test driven development. That way you think about how other people will use the code you write.

This helps tremendously in that regard

QA may be a better path.

This is also sound advice.

 

[Grifter]

In a team environment, your code should above all else be readable, maintainable, and extendable and you may be called out for lacking these if there are code reviews.

 

[mnannola]

I think instead of forcing yourself to jump to QA, you should practice making some simple programs. Do it as structured as you want, but figure out what features you want the program to have, and when you think you can have it done by. Then try to stick to that due date as much as possible. Detail oriented is a good skill to have in programming, but you do have to be able to get the overall project done even if that means it isn't perfect.

 

[ItIsOkBro]

would a detail oriented person really write self contained code that can't interface with anything else

 

[0xCA2]

I appreciate the responses. People have suggested I get into QA; I'm looking into it but it feels like a risky career leap. I fear that if I get into QA I'll have limited opportunities for advancement, etc.

Also, I'll look into test-driven development.

Anyone have any opinions on switching to iT?

Also, to clear a few things up:

Yeah, once you get a real job, you will be pressed for time all the time. sounds like you are a bit OCD and in a field where you are in crunch 365 days a year, you cannot be that guy asking for specs and wasting everyone's time instead of just figuring shit out on your own.

To be fair, no matter what field you go in, they will expect you to 'get it', figure stuff out on your own instead of spoon feeding you everything. if this sounds harsh then you are in for a rude awakening when you are in the thick of it and having to answer why you couldnt get shit done in the allotted time.

QA might be better suited for you since they have to think of the details and check things programmers usually wouldnt. that said, if you are going to be one of those QA engineers who want a test plan and specs with everything you are going to have problems.

instead of reading books, i would recommend some therapy instead. sort out your ocd and while you may not be able to change your way of thinking, they might be able to help you work around it.

This seems like a misunderstanding; I don't get or need much help from others, in fact I'm the exact opposite. Sometimes I even spend too much time figuring things out on my own when I could've easily just asked someone. I learn primarily by reading source code.

When I said 'get it' I'm referring to understanding the big picture goals of the project and how your specific tasks should help achieve those goals. I could complete the tasks well on my own, but my solution may not be best for the project.

would a detail oriented person really write self contained code that can't interface with anything else

Assuming you actually know what 'detail oriented' means, then yes. Detail oriented thinkers get caught up in the details of their specific tasks and periphery issues can become an afterthought.

And for the record, I didn't say it couldn't interface with anything at all, I said it couldn't interface well.

 

[Two Words]

You're going to have to work on abstracting details until you're actually at the point that you have to implement them. It seems like you want to do a bottom-up approach when a lot of work is done in a top-down pattern. Perhaps what you should focus on is being detailed-oriented on how you are abstracting things. Try to focus on if you're properly abstracting the architecture so that it can change and expand over time. What kind of technology frameworks are you working in?

 

[Newline]

I personally know plenty of colleagues that are perfectly successful developers/engineers even though they are very detail orientated. As frustrating as it is for someone like myself that likes to think using intuition and generally focusses on the bigger picture, it's certainly not necessary in the field.

I'd suggest looking for jobs where you'll be maintaining and updating projects that already have a long life (2 years+). You will hardly ever have to worry about architecture as it's mostly already formed, you'll usually only be tweaking small parts of an already working system. It's the kind of role I myself hate but plenty of other engineers I know love it.

It's also why some engineers love refactoring and others love rewriting. I personally love to rewrite and i'm going to assume you'd rather refactor.

 

[UnemployedVillain]

- I often focus on implementation level details that don't matter.
- I have trouble communicating with team members about big picture concepts. Often info-dump implementation details that they don't care about while missing 'the point'. Often can't process 'the point' without understanding implementation details.
- The code that I write is often very self contained and doesn't interface with the overarching system well at all
- My solutions technically solve the problems I'm given but aren't necesarily best for the goals of the project
- Have a hard time writing architecture unless I've already finished the implementation, at which point its probably too late

These seem like somewhat critical problems, outside of the "detail oriented" thinking. Most of those are things you NEED to be a good software engineer. I think if you're going to be working in the field, you shouldn't resign yourself to not being able to change because that's who you are

 

[0xCA2]

You're going to have to work on abstracting details until you're actually at the point that you have to implement them. It seems like you want to do a bottom-up approach when a lot of work is done in a top-down pattern. Perhaps what you should focus on is being detailed-oriented on how you are abstracting things. Try to focus on if you're properly abstracting the architecture so that it can change and expand over time. What kind of technology frameworks are you working in?

Thanks for the advice. Refocusing my attention in that way is probably a good idea. I think I went through a period where I did do that and I ended up an Architecture Astronaut type guy :X and my attempt to not be that has lead me to this point, But I'll try again. I don't know how to find a proper balance.

I just got off an internship where I did a ruby c extension for a ruby application. I'm going to be working on front-end JS and/or Enterprise java when I start my part time job again.

 

[Fragamemnon]

Talk to your boss and get some coaching. See if you can fix the biggest problem, which is the inability to give people the information they need from you and your tendency to focus and spend time on details that don't matter.

- The code that I write is often very self contained and doesn't interface with the overarching system well at all
- My solutions technically solve the problems I'm given but aren't necesarily best for the goals of the project

Talk to your boss about getting code reviews going, if you are doing this others might be doing this and talking through things out in the open should help people realize this is a problem and develop standards and team practices so this doesn't happen.

- Have a hard time writing architecture unless I've already finished the implementation, at which point its probably too late

Most people don't arch new things very often, this feels like you are trying to architect everything up front instead of getting something stood up and refining on it as its reviewed.

I fear that if I get into QA I'll have limited opportunities for advancement,

I think that even in a QA/SDET style role you'll still issues with the first two bullets in your original post, but you I think you already realize that you will have fewer opportunities for advancement where you are with these characteristics (hence this post).

 

[0xCA2]

Most of those are things you NEED to be a good software engineer. I think if you're going to be working in the field, you shouldn't resign yourself to not being able to change because that's who you are

At one point I went all in on the 'big-picture' stuff and became an architecture astronaut who couldn't write code that actually did anything. So I went to the other end of the spectrum and here I am. Point is, I feel that even If I tried to change those issues I'd probably end up being worse in some other way. Which is why I'm considering just leaving the field.

 

[Somnid]

It's a balance for sure. I see people who get stuck in the weeds and don't realize that in the end they need to ship something to produce value and build up so much boilerplate and optimized code and get stuck when the next iteration requires tearing it all out because things changed.

 

[The Last Wizard]

Do you have to be a programmer with a computer science degree? Isn't it a pretty versatile degree?

 

[0xCA2]

Most people don't arch new things very often, this feels like you are trying to architect everything up front instead of getting something stood up and refining on it as its reviewed.

Nah, the exact opposite. I'm afraid of doing this, so I end up implementing everything first before realizing I should've architected too late.

Also I've never worked in an environment where there was code reviews.

 

[Zoe]

Do you have to be a programmer with a computer science degree? Isn't it a pretty versatile degree?

A CS degree doesn't even necessarily teach you how to program. It's more about logic and concepts.

 

[derder]

Test automation engineers make nearly as much as full stack developers.

 

[prophetvx]

Web / UX development definitely isn't for you. QA or test driven development is definitely a better fit.

Unfortunately to really get ahead in the software game, you need to be a 'big picture' guy, most people in the industry aren't those people though. In my experience less than 10% of dev's are capable of being big picture, so you aren't unique in that regard. The reality is very few people are able to take requirements and determine a path to get there with a well-thought out design.

 

[nullset2]

Your OCD stuff is fine OP, hell, if you channel that impulse into the things that really matter, such as learning how to painstakingly design great algorithms and manage data structures intelligently, you're going to be fantastic at this as a career.

...but in the industry as a whole it's important to have great communication skills, to make your code readable, and to come off "the right way" to everyone else and I think that's your achilles heel.

People don't care about the process, they only care about the results. Don't burden people who don't need to hear about the process with minutia about it. Managers only need to know how long something will take to do and if you can do it.

Just listen more and face your fears of other people more (which I think is a thing that ails most people on the spectrum). You gotta learn to chill a bit and groove with the other people man: with nancy from marketing and lydia the girl with the tattoos on front-end and michael the pasty old DBA guy who never leaves his cubicle. But the effort has to come from you.

 

[The Albatross]

I think you could really do well with the right manager, one who keeps you focused on requirements and deliverables as a Jr. developer. When looking for jobs, I'd look for junior roles where you're going to be given a lot of structure. Those qualities can be very helpful for junior developers and then you can learn prioritization, requirements writing, and how to mitigate those other issues when on the right promotion track.

Ultimately a good manager will probably be a big help for your career.

 

[Gentleman Jack]

- I have trouble communicating with team members about big picture concepts. Often info-dump implementation details that they don't care about while missing 'the point'. Often can't process 'the point' without understanding implementation details.
- The code that I write is often very self contained and doesn't interface with the overarching system well at all
- My solutions technically solve the problems I'm given but aren't necesarily best for the goals of the project
- Have a hard time writing architecture unless I've already finished the implementation, at which point its probably too late
- Often slower because of all of the above

Have you studied design patterns yet? Do you have any opportunities to intern where there is regular code review? Because this all reads like you're trying to write 'perfect' code at the expense of everything else and that's no bueno in a collaborative environment. Even QA has to be able to see bigger picture problems for what they are and not be the proverbial pixel fascists opening showstopper tickets over low-priority blemishes.

 

[compo]

What you described to me sounds like normal junior level developer problems. Not necessarily details oriented problems. Nobody starts a job and immediately does everything correctly. And most companies hire devs with a long wind up process in mind. You're basically still considered "in training" for like a year. So unless you're explicitly fired, I wouldn't necessarily give up, OP. You'll get the hang of things if you stick with it.

Also, you should take some time to think before making a drastic change in career paths. Q&A and IT are both computer careers, but they're not software development. You can't really use experience in Q&A or IT to transfer to a software development job, so if you spend too much time in those fields, then you'll negate your software development school experience, and will have to jump through a bunch of hoops again to try to build up software development experience for your resume.

I'm not necessarily trying to dissuade you from going to Q&A or IT. I'm just making sure you know that you'll be losing your software development experience, and will have to rebuild it up again if you ever decide to get back into software development.

Ultimately, you have to do what makes you happy. Q&A and IT are still great career paths. I think you can pull software development off though, if you give it enough time.

 

[Zoe]

Also, you should take some time to think before making a drastic change in career paths. Q&A and IT are both computer careers, but they're not software development. You can't really use experience in Q&A or IT to transfer to a software development job, so if you spend too much time in those fields, then you'll negate your software development school experience, and will have to jump through a bunch of hoops again to try to build up software development experience for your resume.

I'm not necessarily trying to dissuade you from going to Q&A or IT. I'm just making sure you know that you'll be losing your software development experience, and will have to rebuild it up again if you ever decide to get back into software development.

Ultimately, you have to do what makes you happy. Q&A and IT are still great career paths. I think you can pull software development off though, if you give it enough time.

QA (no &) can definitely include programming and benefits from someone having a CS background.

 

[dragonelite]

Pretty sure most of us post college are like this, then the field breaks you and forces you to abandon such an approach.



This helps tremendously in that regard



This is also sound advice.

That was mine experience, but sometimes it really depends how much business driven the company is.
Sometimes a more engineering driven company or research centrum does give you the time to think a bit longer about the details.

But QA or test automation might be a good way to go, i wish i had someone that could do it in my team.
Wire up the code to fitnesse or whatever test framework and automate the whole integration part of the project so i can focus on features and some of the low level unit tests.

 

[Wowfunhappy]

I will just note that my company works with a couple of outside, freelance web developers, who we hire to build relatively small websites on their own. We give them designs, and they build it, without any other developers (except for one internal tech director who will sometimes contribute). So there are jobs for people who just want to work by themselves.

Mind you, I have no idea how common this is in the industry overall, and I'd imagine these devs make less than they could in a larger company. Then again, there are perks too—I know at least one of them in particular makes a point of never working more than half the year.

 

[HammerOfThor]

A couple things:

Are these thoughts based on your experience or negative reviews from internships?

Do you legitimately enjoy programming?

Honestly, its hard to get the big picture of a system that your only on for a few months during an internship. Once you step into the real world, employers will spend a bit more time making sure you know the ins and outs of their company/system.

Also, it takes experience. It was hard for me at first too but unless your a consultant, you will have a lot more time understanding what it is the system and company are doing.

Also, its always a lot easier to start on a new project then be onboarded to an existing one. Sometimes team members are just accustomed to everything they won't always communicate stuff well since to them its second nature.

I guess my point is, your already this far, finish up with your degree and give software development an honest, full-time, go. If you don't enjoy it, try QA or something similar. I wouldn't back out now when your almost done.

 

[subrock]

I think I've worked with your type before OP. We had a guy a couple summers ago that was mired in details like you say and if he were here today this is the advice I'd give him:

- Don't try to fix other people's work. This guy would jump onto a feature that was purposely made small and self-contained. He would be working on something for a few days without much to show for it and when I'd check in to see how things were going he'd touched a dozen or so files to add a small piece of UI. When I asked him about why he thought he needed to change things, most of the time the reason was just that it bugged him, or he was having a hard time reading it how it was so he reorganized it. When you are an underling that's implementing UI or small jobs, stick to your work and if you see things that need changing make a task for yourself and commit separately. That way a more senior coder can decide if it's worth doing and prioritize it for you.

- Have a light touch. Try to write as little code as possible in your features. This doesn't mean making insane ternary operators or naming your variables "var v = View()". What it does mean is don't branch out to unrelated files unless you absolutely need to, keep your interfaces clean and be diligent about access control to only expose the necessary interface, be organized. If you go to make a pull request with a new piece of UI or feature and it's 1000+ lines, make damn sure there's a good reason for it.

- Review your own work before making others do it. Before you click "open pull request" read through your commit. Look for errant whitespace commits, accidentally committed files, and make sure you have a reason for what you wrote. You should be able to sit beside someone that's reviewing your code and tell them why you added each line.

- When you're learning, learn. Summer intern guy would constantly argue with me about the way things were built and would fight tooth and nail for the way it should be. It's absolutely okay to look at an application and think "maybe there's a better way" but it's also to important to acknowledge the thousands of commits required to build an application. Trying to grab the reins of an application as a less experienced developer is a selfish move. Be constructive about feeding back to make an app better but if someone more experienced says "thanks but no" you need to just move on. Listen to your elders and try to not repeat your mistakes.

- Don't be a lone wolf. This is kinda covered in the other points but make sure you are working in such a way that others can work around you. If you are biting off giant features for yourself and making "oops" commits all over the place you are going to make it hard for anyone to jump in to help you. I've noticed this tendency with devs that were once solo freelancers and it's a hard habit to break it seems.

- Don't ever commit "oops". I will cut you. "git commit --fixup [commit-hash]" will make a "fixup" commit for you and then "git rebase -i --autosquash HEAD~[n commits]" will clean up your work later.

 

[compo]

QA (no &) can definitely include programming and benefits from someone having a CS background.

That's true. There's programming involved in automating tests, and most likely other things. I admittedly don't know that particular field too well. But my point was that if OP drops out of web app development to pursue QA, then decides years later that he/she wants to get back into web app dev, then OP is going to have to work on building up the resume again with side projects or something, since it will be difficult to get into web development with just QA experience and older school experience.

Also, just in case I'm not being clear, I don't mean to discount QA. That's a great career path that I'm sure OP would be happy in. I'm just making sure OP understands the point above about getting back into web app development after leaving it.

 

[IlGialloMondadori]

Maybe you should start to do test driven development. That way you think about how other people will use the code you write.

This is excellent advice. This helps you think about pieces that you need, and how they'll be used.

 

[Newline]

- Don't ever commit "oops". I will cut you.

There'd be a bloodbath at my workplace then.

 

[subrock]

There'd be a bloodbath at my workplace then.

I know lots of places do it, but it's just lazy as fuck. It's like someone that's cooking a meal and stacking dirty dishes on every available surface. Clean as you go and the tidy at the end will be easy. Fixup commits are even arguably easier than "oops". I would also judge a junior way more favorably if they used fixups over shitty commit messages

 

[butzopower]

Weird question, but how old are you OP and how many years have you been at it? Sometimes you just have to find a frame of mind that works for you, a set of rules that let you focus. Honestly, if you can find a way to do pair programming, it would be ideal for your situation, since your pair has to keep you focus, and you have to keep them honest.

 

[prophetvx]

I know lots of places do it, but it's just lazy as fuck. It's like someone that's cooking a meal and stacking dirty dishes on every available surface. Clean as you go and the tidy at the end will be easy. Fixup commits are even arguably easier than "oops". I would also judge a junior way more favorably if they used fixups over shitty commit messages

Try managing outsourced talent (and I use the term loosely), I nearly have a stroke weekly trying to manage guys who upper management think are worth the cost. I've fired 6 guys in the last month alone that think "end of day commit" is a suitable use for version control and merging code across multiple feature branches contaminating the entire code pool.

It boggles my mind how people have no idea how to use SCM and it doesn't matter how many times you explain it, they still eventually fall into bad habits. You either get it or you don't.

 

[subrock]

Try managing outsourced talent (and I use the term loosely), I nearly have a stroke weekly trying to manage guys who upper management think are worth the cost. I've fired 6 guys in the last month alone that think "end of day commit" is a suitable use for version control and merging code across multiple feature branches contaminating the entire code pool.

It boggles my mind how people have no idea how to use SCM and it doesn't matter how many times you explain it, they still eventually fall into bad habits. You either get it or you don't.

props for fighting the good fight. I'm a hard ass when it comes to that stuff, mostly because it keeps the whole team sane when you write reviewable code in properly sized commits. If you're on my team and trying to get away with that shit I'll just reject it all day long until it's right.

 

[SlimySnake]

This seems like a misunderstanding; I don't get or need much help from others, in fact I'm the exact opposite. Sometimes I even spend too much time figuring things out on my own when I could've easily just asked someone. I learn primarily by reading source code.

When I said 'get it' I'm referring to understanding the big picture goals of the project and how your specific tasks should help achieve those goals. I could complete the tasks well on my own, but my solution may not be best for the project.

i know people like you. I have worked with them.

if you are writing shit code, you will be told that during the peer review or senior technical review part of the project. they will tell you whats wrong with it and you will eventually learn. they will teach you the best practices and if you dont follow them thats on you.

bottom line is that you will have to do what they say. if you can do that you will survive. if you are going to ask for detailed specs and have a dozen meetings with senior staff over simple things then they wont tolerate you for long.

so keep that in mind and go find a job. you will have to learn from your mistakes and like everyone else in the universe, learn on the job. good companies give their noobies 6-12 months to learn on the job. good companies dont just have rookies do complicated tasks without providing guidance.

 

[dragonelite]

That's true. There's programming involved in automating tests, and most likely other things. I admittedly don't know that particular field too well. But my point was that if OP drops out of web app development to pursue QA, then decides years later that he/she wants to get back into web app dev, then OP is going to have to work on building up the resume again with side projects or something, since it will be difficult to get into web development with just QA experience and older school experience.

Also, just in case I'm not being clear, I don't mean to discount QA. That's a great career path that I'm sure OP would be happy in. I'm just making sure OP understands the point above about getting back into web app development after leaving it.

Last time i did some serious web app development was a couple of years ago.
The landscape completely changed in those couple of years, things like build systems, frameworks and programming paradigms.

A couple off years not doing web app development seems like you need to start almost from zero again.
But you have a couple of years of experience under your belt so you can pick things up a shit load faster.

 

[Kieli]

Do NOT go into QA. I repeat. DO. NOT. GO. INTO. QA.

It's a dead-end path that's not respected by your bosses and peers (1) it's been outsourced to India, my entire QA department was gutted down to a handful of people and (2) companies are more and more expecting the dev people to do the QA job (essentially a 2-for-1 deal).

Most software shops don't give a shit about quality, and it shows in how the QA is treated.

Just don't do it. You're irrevocably fucking over your career. Maybe consider QA when your 50 and nearing retirement or something.

 

[0xCA2]

Anybody have any good resources for learning about design patterns and/or modern application development/web development practices?

I'm going to try test myself this week by building a website while writing the least amount of code as possible.

 

[Painguy]

Become a verification engineer.

 

[family_guy]

Get a state job. You'll be fine. Most code is crap.

 

[deadbeef]

Do NOT go into QA. I repeat. DO. NOT. GO. INTO. QA.

It's a dead-end path that's not respected by your bosses and peers (1) it's been outsourced to India, my entire QA department was gutted down to a handful of people and (2) companies are more and more expecting the dev people to do the QA job (essentially a 2-for-1 deal).

Most software shops don't give a shit about quality, and it shows in how the QA is treated.

Just don't do it. You're irrevocably fucking over your career. Maybe consider QA when your 50 and nearing retirement or something.

This is pretty accurate IME.

 

[joelseph]

If you don't like to Dev why not look into DevOps or DevTools? IT is shit until you get past the initial entry point.

 

[Khrno]

Do NOT go into QA. I repeat. DO. NOT. GO. INTO. QA.

It's a dead-end path that's not respected by your bosses and peers (1) it's been outsourced to India, my entire QA department was gutted down to a handful of people and (2) companies are more and more expecting the dev people to do the QA job (essentially a 2-for-1 deal).

Most software shops don't give a shit about quality, and it shows in how the QA is treated.

Just don't do it. You're irrevocably fucking over your career. Maybe consider QA when your 50 and nearing retirement or something.

I can say this is 100% true for a company as Sony where I worked at for 8 years.

But now I'm in an e-commerce company, they have their own QA department which assigns testers to the projects, I entered the company as QA but I went away from that path pretty fast and within a year I became a Project Manager. SO I have to say our QA department is very extensive, everyone is given proper training, certifications and opportunities, and many people that just started as QA, soon moved to either PM roles or development roles either programming or becoming Business Analysts or Solution Architects.

It all depends the type of company you land on, but after seeing the situation on my current company I can say that there are very good places to work out there and want to help their own employees to grow on their career paths.

Also, this company pays an entry-level QA tester 3 times more than SCEE did to their 8+ years lead testers.