Welcome Guest ( Log In | Register )

Outline · [ Standard ] · Linear+

 Career Advice

views
     
malleus
post Jan 13 2021, 10:39 AM

Look at all my stars!!
*******
Senior Member
2,096 posts

Joined: Dec 2011
QUOTE(Find The Way @ Jan 12 2021, 06:52 PM)
Haha... I removed details as the question is already pretty long, can be sleepy to read  sweat.gif

Complexity wise, the product team consists of multiple project teams, reporting to multiple managers. Project team size was usually 4-5 engineers, for duration 3-6 months. Larger projects were less common, can go up to a year. Most of our team's components are web services and event subscriber/processor. Within the company, there were other products that depending on ours, and we too depended on some other product teams' works.

Context of problem can be lengthy... I'll try to shorten it by commonly observed pattern. It usually went like... project team implementing design halfway, discovered certain things do not work per expected. Investigation often ended up that part of design was based on assumptions, which turned out to be invalid. Assumptions fall under three areas:
1. Ambiguous area in requirements ==> this was solved after the team adopted diff strategy. After received design, engineers will redo requirement analysis to identify potential gaps between understandings of product manager and architect.
2. How chosen library/tool/framework works ==> we didn't change this kind of dependency after the first three years, once stabilised this pain was gone
3. How upstream/downstream product dependency work (technical aspect) ==> this was usually discovered during integration test
4. Current state of system (gap between ideal design vs workaround designs that were actually implemented in the past)

After the first three years, we were left mainly #3 and #4. #4 was probably whole product team's issue rather than architect alone's, no one (including me) had motivation to keep track on those gaps.
@bumpo
For uncontrollable factors such as underfunded projects, they occurred to us occasionally, not on regular basis. Normally project team will be told upfront about it, they are understandable, never heard any of my teammates making noise about it (sigh doesn't count as noise tongue.gif ). In my opinion, if uncontrollable factors happen regularly and causing engineers to be burn from time to time, I reckon it is more of "environment" issue - product specific, org specific or industry specific. So the only two options are accept and find mitigative workaround, or move on to different environment. It has nothing much to do with competency of architect or manager. Just my two cents smile.gif
*
Earlier when you mentioned promoted to manager, are you talking about product manager? or manager for the dev teams?

For now I'll just assume you're meaning product manager, so correct me if I'm wrong with my assumption.

Moving from a dev to roles like product manager or solution architect is not a binary thing. These roles may overlap depending on the environment, and I personally will encourage ppl to explore outside of their dedicated job area despite them not wanting to move to those role types.

Like for example, devs can get actively involved in architecture discussions, or can also get involved in business analysis work too. This greatly helps with breaking down of the walls between the roles, and very much avoids the 'not my responsibility' issue. And it also helps to better identify who are the candidates that can be moved to other role types, as well as allow these ppl a better idea if they'll even like these other role types or not.

Looking at the role of the architect, my take on it is that the role is more focused on managing the architecture rather than coming out with the architecture. by that what I mean is, he can come up with an initial draft, but finalizing is done together with the relevant dev team members. his role after that will be to check in with the devs if the adopted architecture is giving any issues along the way, and try to anticipate any future issues based on reports from the devs too. the key important thing is collaboration rather than total segregation of responsibilities. Tracking the issues you mentioned in 4) should be the entire team helping to do it, but the architect needs to be the one to drive it (assuming he's also playing the role of the team lead)

For 3) the way we address this is to automate integration tests as early as possible. Then do nightly runs so there can be early alerts should there be any changes to upstream/downstream that's not announced. but this does require collaboration with the different teams as well.



Find The Way
post Jan 13 2021, 01:13 PM

Enthusiast
*****
Senior Member
724 posts

Joined: Nov 2004


QUOTE(malleus @ Jan 13 2021, 10:39 AM)
Earlier when you mentioned promoted to manager, are you talking about product manager? or manager for the dev teams?

For now I'll just assume you're meaning product manager, so correct me if I'm wrong with my assumption.

...
*
I was referring to dev team manager, not product manager. Sorry for the ambiguity.


QUOTE(malleus @ Jan 13 2021, 10:39 AM)
...
Like for example, devs can get actively involved in architecture discussions, or can also get involved in business analysis work too. This greatly helps with breaking down of the walls between the roles, and very much avoids the 'not my responsibility' issue. And it also helps to better identify who are the candidates that can be moved to other role types, as well as allow these ppl a better idea if they'll even like these other role types or not.
...
*
I agree with this. If I'm in dev team manager's position and want to apply this idea to my team, is it advisable to communicate this as explicit direction? or silently let the team evolve into this pattern over the time?


QUOTE(malleus @ Jan 13 2021, 10:39 AM)
...

Looking at the role of the architect, my take on it is that the role is more focused on managing the architecture rather than coming out with the architecture. by that what I mean is, he can come up with an initial draft, but finalizing is done together with the relevant dev team members. his role after that will be to check in with the devs if the adopted architecture is giving any issues along the way, and try to anticipate any future issues based on reports from the devs too. the key important thing is collaboration rather than total segregation of responsibilities.
...
*
In that product team's situation, by the time dev team onboard to project, timelines that were already committed usually won't be feasible for the team to go back to architecture design or redesign activities. If that was indeed an intentional strategy by the architect, then there must be communication issue or misalignment between architect's strategy and dev team manager's strategy.


QUOTE(malleus @ Jan 13 2021, 10:39 AM)
...
For 3) the way we address this is to automate integration tests as early as possible. Then do nightly runs so there can be early alerts should there be any changes to upstream/downstream that's not announced. but this does require collaboration with the different teams as well.
*
Hmm... unless there's an easy way to do integration tests without building our pieces first, rework is still unavoidable, right? If it's small issue that can be solved with minor fix, that's alright. It would be painful to meet deadline if considerable amount of redesign/re-implementation is required (not to mention testing and automation work might need to be partially redo as well).

malleus
post Jan 13 2021, 02:03 PM

Look at all my stars!!
*******
Senior Member
2,096 posts

Joined: Dec 2011
QUOTE(Find The Way @ Jan 13 2021, 01:13 PM)
I was referring to dev team manager, not product manager. Sorry for the ambiguity.
I agree with this. If I'm in dev team manager's position and want to apply this idea to my team, is it advisable to communicate this as explicit direction? or silently let the team evolve into this pattern over the time?
Being silent is never a good idea. I won't put it as an explicit direction either. A mistake that many make in such a position is trying to take too much to themselves. You may have a rough idea of how you want to approach the problem, but you need to validate it properly first right? Instead of doing it on your own, get the team involved. Slice things up into different spikes to explore, then ask first for volunteers on who wants to do which spike, then for the left over, do the assignment. In other words, work together with the team on this. This will get the team to feel like they have more control over things as well, as they have a direct feedback loop on if the spike does not turn out well and there's a need to rethink that particular component.

QUOTE(Find The Way @ Jan 13 2021, 01:13 PM)
In that product team's situation, by the time dev team onboard to project, timelines that were already committed usually won't be feasible for the team to go back to architecture design or redesign activities. If that was indeed an intentional strategy by the architect, then there must be communication issue or misalignment between architect's strategy and dev team manager's strategy.
Hmm... unless there's an easy way to do integration tests without building our pieces first, rework is still unavoidable, right? If it's small issue that can be solved with minor fix, that's alright. It would be painful to meet deadline if considerable amount of redesign/re-implementation is required (not to mention testing and automation work might need to be partially redo as well).
*
Senior key devs will need to be identified and onboarded to a project right from the initial kick off right away, and be involved in not only the architecture, but also the project strategy. Their input will be critical when it comes to timeline estimations. These may not need to be the most senior of the devs, as not all devs will be interested in this. But there'll definitely be those who want to explore outside of just their normal dev work who will be suitable.
TSjeff87s2
post Jan 13 2021, 07:22 PM

New Member
*
Newbie
12 posts

Joined: Dec 2012
QUOTE(malleus @ Dec 30 2020, 08:00 AM)

Another interesting thing that I observed in a number of startups (I'm talking about the late stage startups that's been around for a few years) is that they often struggle with having developers who are too inexperienced when it comes to scaling up to numbers of like 100+ ppl in the organisation. Hence there'll always be a need for more experienced ppl, but having said that, you'll also need to make sure that you have sufficient exposure to be able to fulfill such roles later. You do not need to be better or faster than the younger developers. An example was this particular place I interviewed at last year, where they're looking for more experienced generalists to be able to guide the younger engineers. Being able to talk about your past failures or disasters you're involved in helps a lot too. Especially when it comes to, what you have learnt from it, how to spot the same thing potentially happening again and ring the alarm bell, and how to resolve such issues if it happens again.
*
I have some sort of same feeling like even right now people with team lead ,architect etc title in my opinion they also having trouble or struggle when coming to scaling if they do not enough relevant exposure.
TSjeff87s2
post Jan 13 2021, 07:29 PM

New Member
*
Newbie
12 posts

Joined: Dec 2012
QUOTE(silverhawk @ Dec 30 2020, 01:59 PM)
You cannot wait for something to happen, you need to make it happen. If your current company has a project, ask if you can take charge of it. Or if they don't, propose a project.

The confidence should not be at the result of a project, but confidence in yourself and your abilities. Be confident that if you don't know something, you'll learn. Be confident in yourself that if you can't figure it out, you'll seek help from someone who can. Be confident that you can make the hard choices and live with its consequences.

Having a mentor is great, but you don't necessarily have to work with a mentor. As long as you are in contact with some people with experience and knowledge that you can respect; they are only an e-mail away when you need some help/advice. Forums like this also give you access to expertise and experience.

At the end of the day, the best mentor will be your own experience. So you need to get your feet wet, put yourself at some risk, then you will grow.
*

Yes i can make it happen but if i always do the way in my own perspective only i do not think i can grow further . Like as said last year i lead a react mobile app but successfully deliver it but i only do in what i think is good only but there are sure room for improvement. If there is a mentor(not random people) , at least can give some perspective, like during junior time , you will like feel a WOW moment when you seeing maybe how senior do the thing differently but coming to now, i feel like reaching the bottleneck of my technical skill ( i not sure do you guy feel that). I can deliver project but if do not go for better way of doing it then will be just delievering project only.
TSjeff87s2
post Jan 13 2021, 07:41 PM

New Member
*
Newbie
12 posts

Joined: Dec 2012
QUOTE(malleus @ Jan 13 2021, 10:39 AM)
For 3) the way we address this is to automate integration tests as early as possible. Then do nightly runs so there can be early alerts should there be any changes to upstream/downstream that's not announced. but this does require collaboration with the different teams as well.
*
Just seek your advice from once i read from martin fowler ,to implement continuous integration, we should only have 1 branch and push the code every day otherwsie not really consider continuous integration,

but we currently using feature branch strategy , this is good for control of the release much better but at the same time if the feature branch divert so long from master branch then will be pain when solving the conflict later and might

need to retest if after that.

so if only 1 branch then i read got something like feature toggle to control release feature but this seems does not make sense to me as we need to have toggle feature hardcorded into the code and hard to implement as well.

so any advice on how to implement continuous integration with better control of the release?

This post has been edited by jeff87s2: Jan 13 2021, 07:48 PM
malleus
post Jan 13 2021, 10:29 PM

Look at all my stars!!
*******
Senior Member
2,096 posts

Joined: Dec 2011
QUOTE(jeff87s2 @ Jan 13 2021, 07:41 PM)
Just seek your advice  from once i read from martin fowler ,to implement  continuous integration, we should only have 1 branch and push the code every day otherwsie not really consider continuous integration,

but we currently using feature branch strategy , this is good for control of the release much better but  at the same time if the feature branch divert so long from master branch then will be pain when solving the conflict later and might

need to retest if after that.

so if only 1 branch then i read got something like feature toggle to control release feature but this seems does not make sense to me as we need to have toggle feature hardcorded into the code and hard to implement as well.

so any advice on how to implement continuous integration with better control of the release?
*
There's a need to understand the context where Martin Fowler is speaking from. Being from Thoughtworks, its very likely that he's speaking from the Thoughtworks context, where the internal practice is trunk based development. All changes goes into the master/main branch. The internal practice is also to use feature toggles are used to control features not ready to go into release. At the start of a project, thought is already given to how to feature toggle easily, and it's activated/deactivated via env variables passed in from the CI. Then looking at the CI env variables, you can determine which are still needed, and which are no longer needed and can be removed from the code. I've worked with this method, and it works well.

However it's not the only way of doing things. The method you mentioned is more similar to gitflow, which works as well. When there's a fix that needs to be done, I first ask myself, is this fix applicable to only the feature/release branch? or does main/master require it as well. most times, main/master also needs it. So I make the changes to master/main first. Then I do a cherry-pick into the feature/release branch. updates to the feature/release branches are done directly only and if only I am very sure that the changes do not need to be in master/main as well, which is actually quite seldom.

This post has been edited by malleus: Jan 13 2021, 10:30 PM
malleus
post Jan 13 2021, 10:40 PM

Look at all my stars!!
*******
Senior Member
2,096 posts

Joined: Dec 2011
QUOTE(jeff87s2 @ Jan 13 2021, 07:22 PM)
I have some sort of same feeling like even right now people with team lead ,architect etc title  in my opinion they also having trouble or struggle when coming to scaling if they do not enough relevant exposure.
*
this is indeed the very nature of the industry. and to get exposure really means there's a need to change jobs every few years. in SG, the average in IT is actually 18 months.

This can be quite difficult for most places to accept, especially the more traditionally run companies. but this same reason is also why they're not able to attract the talent that they need.

In most places, once a person leaves, that's the end, will never hear from them again, or even keep in contact. What the smarter companies does is, to try to main active contact, see how they're doing, etc. Then 2-3 years later see if they're willing to return or not. For those who leave because they're wanting exposure to other things, there's a good chance that they will be willing to if the offer is good.

Interestingly, that old cranky chinaman my father had as a boss decades ago had the same thinking too. and he's willing to pay well to bring ppl back once they've gotten the experience he deems will be valuable. unfortunately these are the only 2 good points about that guy from the stories I heard.
Find The Way
post Jan 19 2021, 11:19 AM

Enthusiast
*****
Senior Member
724 posts

Joined: Nov 2004


QUOTE(malleus @ Jan 13 2021, 02:03 PM)
Being silent is never a good idea. I won't put it as an explicit direction either. A mistake that many make in such a position is trying to take too much to themselves. You may have a rough idea of how you want to approach the problem, but you need to validate it properly first right? Instead of doing it on your own, get the team involved. Slice things up into different spikes to explore, then ask first for volunteers on who wants to do which spike, then for the left over, do the assignment. In other words, work together with the team on this. This will get the team to feel like they have more control over things as well, as they have a direct feedback loop on if the spike does not turn out well and there's a need to rethink that particular component.
...
*
QUOTE(malleus @ Jan 13 2021, 02:03 PM)
...
Senior key devs will need to be identified and onboarded to a project right from the initial kick off right away, and be involved in not only the architecture, but also the project strategy. Their input will be critical when it comes to timeline estimations. These may not need to be the most senior of the devs, as not all devs will be interested in this. But there'll definitely be those who want to explore outside of just their normal dev work who will be suitable.
*
Life could have been much better if you were the manager for that product team biggrin.gif

Find The Way
post Jan 19 2021, 12:08 PM

Enthusiast
*****
Senior Member
724 posts

Joined: Nov 2004


QUOTE(Find The Way @ Jan 11 2021, 11:35 PM)
Interesting discussion... One question regarding advancing software engineer's career to next stage, be it software architect or manager. If any of you went through this process before, how long did you take to become competent in your new role?
...
*
It seems that my question could be a bit too broad and hard to come out with a generally acceptable guideline. Different organisations might define role and responsibility differently even for the same title. For instance, the possibility raised by @malleus ~ software architect to manage architecture design rather than to produce architecture design, is refreshing to me. Without knowing how the organisation defines roles, usefulness of the estimate is questionable.

M_Shahrul
post Jan 22 2021, 02:25 PM

On my way
****
Senior Member
635 posts

Joined: Apr 2010
From: Kuala Lumpur


QUOTE(jeff87s2 @ Dec 28 2020, 12:53 AM)
OK i am java programmer currently 33 years old ,engineer graduate but become programmer and mostly doing java web banking system. As a senior, currently i mostly give advice on the technical side of new enhancement etc , performing code review and guiding the juniors and sure doing some coding. But my current company still using quite old way or tech at least at the project i am handling right now , like  still not integrate with CI/CD and no unit testing , not practising agile etc, java side mostly still using jsp not like just using java as backend rest service with more advantage front end tech like react ,vuejs as the system are still quite old and there is no planning to revamp plan on it as we are not stakeholder to can make this kind of decision and i feel kinda of limited growth on my technical part.

if only just change to another company but still just focus on project delivery only which i know most company do and this is the most important to the company then i do not think i will grow much except maybe newer tech etc  . And going  to aim for solution architect is gonna to learn to make those technical decision yet i feel i am not ready and competent enough yet.  And fyi i sometime to get to know some newer things not really like i am interested but more likely i feel insecure if not knowing any of it and feel like if too outdated will not be competetive enough in tech market as tech are always evolving though currently i found myself to be outdated arelady.

I am not sure you guy understand my dilemma but if you guy could give me any advise on my career path will be helpful.
*
I wish you well in future. I do. Maybe slightly out of topic, but the shittest part of being a programmer in Malaysia, MOST slightly you'll being given a chance of career progression offer (maybe a level higher) OR increment above RM500.00 ++ is only (USUALLY) when, "Boss, this is my letter, two months notice"...

Been there, done that. Front-end HTML, no problem I'll do, boss. CSS, it's okay without Photoshop Designer maybe I'll could tweak it a bit, boss. What, back-end process behind running in the middle of night in Linux server? Okay I will kawtim it boss. For donkey years I have been working like a dog making other people rich, boss keep changing the car like there's no tomorrow from Honda to Mazda to Hyundai to Merce. Just name it...

But it's okay, I got it it's their company, it's them who were forking out the capital few years back as founders, golfing and hotel lunch to get a project. I am okay with it, I am okay they keep changing the car. But trust me years after years with typical Malaysian RM200-RM300 increment (owh yes, typical Malaysian), your programmers are going to download a Jobstreet, Monster Job or LinkedIn apps, mate...

Thank God if it's not for may parents and wife, I would be in Dhubai or Singapore... F**k Malaysian tech industry!!! Even a fresh grad teacher / lecturer earns better / prospect (I do call monthly pension till death a prospect) than an intelligent programmer. What a nightmare. Horrible.

At last, I quitted and demanded an increment of extra RM2,000 in a new job (still a bloody programmer and doing a dotNET from PHP previously), accepted and succeed then just throw the letter to the boss. And again, f**k Malaysian tech industry!!!

This post has been edited by M_Shahrul: Jan 22 2021, 02:33 PM
TSjeff87s2
post Jan 22 2021, 10:46 PM

New Member
*
Newbie
12 posts

Joined: Dec 2012
QUOTE(malleus @ Jan 13 2021, 10:29 PM)
There's a need to understand the context where Martin Fowler is speaking from. Being from Thoughtworks, its very likely that he's speaking from the Thoughtworks context, where the internal practice is trunk based development. All changes goes into the master/main branch. The internal practice is also to use feature toggles are used to control features not ready to go into release. At the start of a project, thought is already given to how to feature toggle easily, and it's activated/deactivated via env variables passed in from the CI. Then looking at the CI env variables, you can determine which are still needed, and which are no longer needed and can be removed from the code. I've worked with this method, and it works well.

However it's not the only way of doing things. The method you mentioned is more similar to gitflow, which works as well. When there's a fix that needs to be done, I first ask myself, is this fix applicable to only the feature/release branch? or does main/master require it as well. most times, main/master also needs it. So I make the changes to master/main first. Then I do a cherry-pick into the feature/release branch. updates to the feature/release branches are done directly only and if only I am very sure that the changes do not need to be in master/main as well, which is actually quite seldom.
*
yea need to understand his context but he did not explain further .so i have question regarding the release control part so i go to google and find out sometime called feature toggle but just i felt it is hard to implement in my opinion.
TSjeff87s2
post Jan 22 2021, 10:54 PM

New Member
*
Newbie
12 posts

Joined: Dec 2012
QUOTE(M_Shahrul @ Jan 22 2021, 02:25 PM)
I wish you well in future. I do. Maybe slightly out of topic, but the shittest part of being a programmer in Malaysia, MOST slightly you'll being given a chance of career progression offer (maybe a level higher) OR increment above RM500.00 ++ is only (USUALLY) when, "Boss, this is my letter, two months notice"...

Been there, done that. Front-end HTML, no problem I'll do, boss. CSS, it's okay without Photoshop Designer maybe I'll could tweak it a bit, boss. What, back-end process behind running in the middle of night in Linux server? Okay I will kawtim it boss. For donkey years I have been working like a dog making other people rich, boss keep changing the car like there's no tomorrow from Honda to Mazda to Hyundai to Merce. Just name it...

But it's okay, I got it it's their company, it's them who were forking out the capital few years back as founders, golfing and hotel lunch to get a project. I am okay with it, I am okay they keep changing the car. But trust me years after years with typical Malaysian RM200-RM300 increment (owh yes, typical Malaysian), your programmers are going to download a Jobstreet, Monster Job or LinkedIn apps, mate...

Thank God if it's not for may parents and wife, I would be in Dhubai or Singapore... F**k Malaysian tech industry!!! Even a fresh grad teacher / lecturer earns better / prospect (I do call monthly pension till death a prospect) than an intelligent programmer. What a nightmare. Horrible.

At last, I quitted and demanded an increment of extra RM2,000 in a new job (still a bloody programmer and doing a dotNET from PHP previously), accepted and succeed then just throw the letter to the boss. And again, f**k Malaysian tech industry!!!
*
This really depends on company and industry. if a small company with small budget client, literally it is very hard for the boss to give big increment also if you think in your boss shoe. so if want have better pay , you gonna join the company serving the enterprise level client as they are willing to pay.

malleus
post Jan 23 2021, 04:09 PM

Look at all my stars!!
*******
Senior Member
2,096 posts

Joined: Dec 2011
QUOTE(jeff87s2 @ Jan 22 2021, 10:46 PM)
yea need to understand his context but he did not explain further .so i have question regarding the release control part so i go to google and find out sometime called feature toggle but just i felt it is hard to implement in my opinion.
*
The important thing to realise is that such guidelines or recommendations are largely just guidelines and recommendations. There's a need to customise further to what fits your situation the best.

Even for TW with the emphasis on trunk based development, this is only done for backend or web. for mobile releases, it's still gitflow / release branches.


silverhawk
post Jan 23 2021, 10:50 PM

I'm Positively Lustrous
Group Icon
Elite
4,738 posts

Joined: Jan 2003


QUOTE(jeff87s2 @ Jan 13 2021, 07:29 PM)
Yes i can make it happen but if i always do the way in my own perspective only i do not think i can grow further . Like as said last year i lead a react mobile app but successfully deliver it but i only do in what i think is good only but there are sure room for improvement. If there is a mentor(not random people) , at least  can give some perspective, like during junior time , you will like feel a WOW moment when you seeing maybe how senior do the thing differently but coming to now, i feel like reaching the bottleneck of my technical skill ( i not sure do you guy feel that). I can deliver project but if do not go for better way of doing it then will be just delievering project only.
*
The keyword is take risk

Nothing wrong with sticking to what you think is good, that is often times the best way forward. However if you take projects that don't challenge your comfort zone, you will not grow. You grow when you face problems that you've never encountered before. Then you have to think of a solution, find it and you learnt something new. Rinse and repeat this process and you gain a lot of knowledge.

Keep in mind the higher in the hierarchy you go in any job, the less you are hired for "what you know". You get chosen for "how you think", because the higher you go, the more unknowns you face and the company/organization/team will want someone that can hold steady when facing unknown problems.
malleus
post Jan 24 2021, 01:18 AM

Look at all my stars!!
*******
Senior Member
2,096 posts

Joined: Dec 2011
QUOTE(silverhawk @ Jan 23 2021, 10:50 PM)
The keyword is take risk

Nothing wrong with sticking to what you think is good, that is often times the best way forward. However if you take projects that don't challenge your comfort zone, you will not grow. You grow when you face problems that you've never encountered before. Then you have to think of a solution, find it and you learnt something new. Rinse and repeat this process and you gain a lot of knowledge.

Keep in mind the higher in the hierarchy you go in any job, the less you are hired for "what you know". You get chosen for "how you think", because the higher you go, the more unknowns you face and the company/organization/team will want someone that can hold steady when facing unknown problems.
*
An interesting thing to note also is that places trying to look for a 100% fit on the skillsets they need will very seldom be able to hire. and the failure to hire gets worse the more senior the role is too.

Hence looking at aptitude is more important than looking at existing skills. And also for more senior roles, you don't need to be better or faster than the younger developers. You just need to be able to identify situations when you can help prevent them from making horrible mistakes that you've made before.
malleus
post Jan 24 2021, 01:23 AM

Look at all my stars!!
*******
Senior Member
2,096 posts

Joined: Dec 2011
QUOTE(M_Shahrul @ Jan 22 2021, 02:25 PM)
I wish you well in future. I do. Maybe slightly out of topic, but the shittest part of being a programmer in Malaysia, MOST slightly you'll being given a chance of career progression offer (maybe a level higher) OR increment above RM500.00 ++ is only (USUALLY) when, "Boss, this is my letter, two months notice"...

Been there, done that. Front-end HTML, no problem I'll do, boss. CSS, it's okay without Photoshop Designer maybe I'll could tweak it a bit, boss. What, back-end process behind running in the middle of night in Linux server? Okay I will kawtim it boss. For donkey years I have been working like a dog making other people rich, boss keep changing the car like there's no tomorrow from Honda to Mazda to Hyundai to Merce. Just name it...

But it's okay, I got it it's their company, it's them who were forking out the capital few years back as founders, golfing and hotel lunch to get a project. I am okay with it, I am okay they keep changing the car. But trust me years after years with typical Malaysian RM200-RM300 increment (owh yes, typical Malaysian), your programmers are going to download a Jobstreet, Monster Job or LinkedIn apps, mate...

Thank God if it's not for may parents and wife, I would be in Dhubai or Singapore... F**k Malaysian tech industry!!! Even a fresh grad teacher / lecturer earns better / prospect (I do call monthly pension till death a prospect) than an intelligent programmer. What a nightmare. Horrible.

At last, I quitted and demanded an increment of extra RM2,000 in a new job (still a bloody programmer and doing a dotNET from PHP previously), accepted and succeed then just throw the letter to the boss. And again, f**k Malaysian tech industry!!!
*
A quick question for you. In those years you've spent working in the same company, what have you achieved in terms of growth? Are you still doing the same thing? Or have you moved onto different roles? Have you learnt about anything new?

You mentioned that you're still a programmer. But have you given thought to what you want to do next? Only if you can identify that then you'll be able to know better how to get there.

The simple fact about the tech industry is that it's extremely diverse, and it's quite seldom that one will get the chance to get diverse exposure working at the same job. It also evolves very quickly. Due to this, the simple fact is, for proper growth to happen, one needs to constantly gain exposure to new things, and it's quite often that the only way to do this is by looking for a different job. This is the same situation literally anywhere at all.
bumpo
post Jan 25 2021, 10:47 AM

On my way
****
Junior Member
632 posts

Joined: Mar 2013


QUOTE(M_Shahrul @ Jan 22 2021, 02:25 PM)
I wish you well in future. I do. Maybe slightly out of topic, but the shittest part of being a programmer in Malaysia, MOST slightly you'll being given a chance of career progression offer (maybe a level higher) OR increment above RM500.00 ++ is only (USUALLY) when, "Boss, this is my letter, two months notice"...

Been there, done that. Front-end HTML, no problem I'll do, boss. CSS, it's okay without Photoshop Designer maybe I'll could tweak it a bit, boss. What, back-end process behind running in the middle of night in Linux server? Okay I will kawtim it boss. For donkey years I have been working like a dog making other people rich, boss keep changing the car like there's no tomorrow from Honda to Mazda to Hyundai to Merce. Just name it...

But it's okay, I got it it's their company, it's them who were forking out the capital few years back as founders, golfing and hotel lunch to get a project. I am okay with it, I am okay they keep changing the car. But trust me years after years with typical Malaysian RM200-RM300 increment (owh yes, typical Malaysian), your programmers are going to download a Jobstreet, Monster Job or LinkedIn apps, mate...

Thank God if it's not for may parents and wife, I would be in Dhubai or Singapore... F**k Malaysian tech industry!!! Even a fresh grad teacher / lecturer earns better / prospect (I do call monthly pension till death a prospect) than an intelligent programmer. What a nightmare. Horrible.

At last, I quitted and demanded an increment of extra RM2,000 in a new job (still a bloody programmer and doing a dotNET from PHP previously), accepted and succeed then just throw the letter to the boss. And again, f**k Malaysian tech industry!!!
*
most company have practice of job band and with it, its range of salary and benefits. they may use different job grade/level system but largely this concept remains same.

do consider the possibility that you keep seeing similar ranges of salary is because you did not climb up the proverbial ladder and stayed at same level all these time.
mind you this in of itself is not a problem. same do enjoy their comfort zone.
when you move to different company but if you seek out same job scope i.e. same level, then dont expect the $$ to be too different
even when you go overseas, the so call increase you see is from currency exchange/their standard of living/etc.
want to see real difference? challenge yourself and move up the ladder

thats my 2 cents laugh.gif

user posted image

 

Change to:
| Lo-Fi Version
0.0198sec    0.49    5 queries    GZIP Disabled
Time is now: 29th March 2024 - 04:17 PM