Mixing
Asking for more deterministic and easily measured work assignments in new job [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
-1
down vote
favorite
I started a new job about two months ago as a senior software engineer at a software product company. After a few assignments that I found to be reasonably scoped to my level of domain experience, I was assigned an assignment that affects altering our application's architectural fundamentals and is, at the same time, rather nondeterministic in nature and has no end in sight. In other words, it will be a long time before I can bring a closure to this assignment. By "nondeterministic" I mean questions like "What color shirt should I wear to the party?" vs. "Should I wear more or less warm clothing to the hiking trip given the weather forecast?", which would be more deterministic.
At this stage of my tenure with the company, I am primarily interested in building an easily quantifiable performance record and by that I mean the number of Jira tickets closed and the number of file revisions associated with my name in the version control system. Therefore, I want to have many small assignments which I can scope and bring closure to and which are more deterministic in nature, offering a clear sense of direction. I want the management to which I do not report directly to have an easily consumable list of closures associated with my name as opposed to having one large project that is still "work in progress" with no end in sight.
I talked with boss today and explained all this to him. I put it in the perspective of my cognitive style and personality type and tried to sell him the idea of assigning me more reasonably scoped tasks of tactical nature and that I can be more productive that way. I really don't want the long scoped assignment. I offered a temporary fix, which is not a long term solution, hoping to inject a pause-able milestone in the project but they want an architecture overhaul. He said that he would have more small assignments for me but will have to dedicate some time each week to this hellish architectural change.
Is there something else I could do to convince the management that I can be far more productive with narrowly scoped tasks as opposed to high level without damaging their perception of me as a developer? I am all about CLOSURE and I am stimulated by having many small quantifiable closures under my belly than working on long projects that involve lots of analysis and planning. I become very nervous when I don't check something in for a long time, thinking that the lack of tangible accomplishment record will put me on a firing list. That and I'm really more of an implementation, tactical guy who prefers instant gratification than a long term planner/designer/analyst. I want to be an implementation programmer who writes code rather than does architectural designs.
management new-job project-management
asked Oct 16 '13 at 20:55
amphibient
3,20772441
closed as primarily opinion-based by Jim G., CincinnatiProgrammer, IDrinkandIKnowThings, CMW, ChrisF Nov 19 '13 at 22:06
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |Â
up vote
-1
down vote
favorite
I started a new job about two months ago as a senior software engineer at a software product company. After a few assignments that I found to be reasonably scoped to my level of domain experience, I was assigned an assignment that affects altering our application's architectural fundamentals and is, at the same time, rather nondeterministic in nature and has no end in sight. In other words, it will be a long time before I can bring a closure to this assignment. By "nondeterministic" I mean questions like "What color shirt should I wear to the party?" vs. "Should I wear more or less warm clothing to the hiking trip given the weather forecast?", which would be more deterministic.
At this stage of my tenure with the company, I am primarily interested in building an easily quantifiable performance record and by that I mean the number of Jira tickets closed and the number of file revisions associated with my name in the version control system. Therefore, I want to have many small assignments which I can scope and bring closure to and which are more deterministic in nature, offering a clear sense of direction. I want the management to which I do not report directly to have an easily consumable list of closures associated with my name as opposed to having one large project that is still "work in progress" with no end in sight.
I talked with boss today and explained all this to him. I put it in the perspective of my cognitive style and personality type and tried to sell him the idea of assigning me more reasonably scoped tasks of tactical nature and that I can be more productive that way. I really don't want the long scoped assignment. I offered a temporary fix, which is not a long term solution, hoping to inject a pause-able milestone in the project but they want an architecture overhaul. He said that he would have more small assignments for me but will have to dedicate some time each week to this hellish architectural change.
Is there something else I could do to convince the management that I can be far more productive with narrowly scoped tasks as opposed to high level without damaging their perception of me as a developer? I am all about CLOSURE and I am stimulated by having many small quantifiable closures under my belly than working on long projects that involve lots of analysis and planning. I become very nervous when I don't check something in for a long time, thinking that the lack of tangible accomplishment record will put me on a firing list. That and I'm really more of an implementation, tactical guy who prefers instant gratification than a long term planner/designer/analyst. I want to be an implementation programmer who writes code rather than does architectural designs.
management new-job project-management
asked Oct 16 '13 at 20:55
amphibient
3,20772441
closed as primarily opinion-based by Jim G., CincinnatiProgrammer, IDrinkandIKnowThings, CMW, ChrisF Nov 19 '13 at 22:06
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
I think they do. This issue predates my start date with the company. I think it should have been attended before I even started. I think other team members didn't want to work on it because they knew how thankless and open ended it would be to work on it, and unredeemable for quantifiable accomplishment credits. Because why else would it still be outstanding? I think someone more senior than me should be doing this architectural refactoring.
– amphibient
Oct 16 '13 at 21:20
1
If you're checking in revisions to vcs on a major project how is that not quantifiable? Just push/merge (if you're using git, replace with your vcs terminology otherwise) a couple times a day, then you'll have measured progress. Closing minor tickets that take <2 days to solve is not generally a responsibility of leads/seniors. Take it as a challenge and embrace the development of your skillset!
– Andrew Bartel
Oct 17 '13 at 1:14
i am saying that i am not checking such changes in because the project is analysis-heavy up front...
– amphibient
Oct 17 '13 at 1:18
1
Easily measured work assignment != Senior engineer work. That is for juniors and less experienced positions. How do I get paid at a senior engineer rate while only having junior engineer expectations would be a more accurate title for this question.
– IDrinkandIKnowThings
Nov 14 '13 at 1:32
add a comment |Â
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
I started a new job about two months ago as a senior software engineer at a software product company. After a few assignments that I found to be reasonably scoped to my level of domain experience, I was assigned an assignment that affects altering our application's architectural fundamentals and is, at the same time, rather nondeterministic in nature and has no end in sight. In other words, it will be a long time before I can bring a closure to this assignment. By "nondeterministic" I mean questions like "What color shirt should I wear to the party?" vs. "Should I wear more or less warm clothing to the hiking trip given the weather forecast?", which would be more deterministic.
At this stage of my tenure with the company, I am primarily interested in building an easily quantifiable performance record and by that I mean the number of Jira tickets closed and the number of file revisions associated with my name in the version control system. Therefore, I want to have many small assignments which I can scope and bring closure to and which are more deterministic in nature, offering a clear sense of direction. I want the management to which I do not report directly to have an easily consumable list of closures associated with my name as opposed to having one large project that is still "work in progress" with no end in sight.
I talked with boss today and explained all this to him. I put it in the perspective of my cognitive style and personality type and tried to sell him the idea of assigning me more reasonably scoped tasks of tactical nature and that I can be more productive that way. I really don't want the long scoped assignment. I offered a temporary fix, which is not a long term solution, hoping to inject a pause-able milestone in the project but they want an architecture overhaul. He said that he would have more small assignments for me but will have to dedicate some time each week to this hellish architectural change.
Is there something else I could do to convince the management that I can be far more productive with narrowly scoped tasks as opposed to high level without damaging their perception of me as a developer? I am all about CLOSURE and I am stimulated by having many small quantifiable closures under my belly than working on long projects that involve lots of analysis and planning. I become very nervous when I don't check something in for a long time, thinking that the lack of tangible accomplishment record will put me on a firing list. That and I'm really more of an implementation, tactical guy who prefers instant gratification than a long term planner/designer/analyst. I want to be an implementation programmer who writes code rather than does architectural designs.
management new-job project-management
asked Oct 16 '13 at 20:55
amphibient
3,20772441
I started a new job about two months ago as a senior software engineer at a software product company. After a few assignments that I found to be reasonably scoped to my level of domain experience, I was assigned an assignment that affects altering our application's architectural fundamentals and is, at the same time, rather nondeterministic in nature and has no end in sight. In other words, it will be a long time before I can bring a closure to this assignment. By "nondeterministic" I mean questions like "What color shirt should I wear to the party?" vs. "Should I wear more or less warm clothing to the hiking trip given the weather forecast?", which would be more deterministic.
At this stage of my tenure with the company, I am primarily interested in building an easily quantifiable performance record and by that I mean the number of Jira tickets closed and the number of file revisions associated with my name in the version control system. Therefore, I want to have many small assignments which I can scope and bring closure to and which are more deterministic in nature, offering a clear sense of direction. I want the management to which I do not report directly to have an easily consumable list of closures associated with my name as opposed to having one large project that is still "work in progress" with no end in sight.
I talked with boss today and explained all this to him. I put it in the perspective of my cognitive style and personality type and tried to sell him the idea of assigning me more reasonably scoped tasks of tactical nature and that I can be more productive that way. I really don't want the long scoped assignment. I offered a temporary fix, which is not a long term solution, hoping to inject a pause-able milestone in the project but they want an architecture overhaul. He said that he would have more small assignments for me but will have to dedicate some time each week to this hellish architectural change.
Is there something else I could do to convince the management that I can be far more productive with narrowly scoped tasks as opposed to high level without damaging their perception of me as a developer? I am all about CLOSURE and I am stimulated by having many small quantifiable closures under my belly than working on long projects that involve lots of analysis and planning. I become very nervous when I don't check something in for a long time, thinking that the lack of tangible accomplishment record will put me on a firing list. That and I'm really more of an implementation, tactical guy who prefers instant gratification than a long term planner/designer/analyst. I want to be an implementation programmer who writes code rather than does architectural designs.
management new-job project-management
asked Oct 16 '13 at 20:55
amphibient
3,20772441
edited Oct 16 '13 at 22:34
asked Oct 16 '13 at 20:55
amphibient
3,20772441
asked Oct 16 '13 at 20:55
amphibient
3,20772441
asked Oct 16 '13 at 20:55
amphibient
3,20772441
3,20772441
closed as primarily opinion-based by Jim G., CincinnatiProgrammer, IDrinkandIKnowThings, CMW, ChrisF Nov 19 '13 at 22:06
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as primarily opinion-based by Jim G., CincinnatiProgrammer, IDrinkandIKnowThings, CMW, ChrisF Nov 19 '13 at 22:06
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
I think they do. This issue predates my start date with the company. I think it should have been attended before I even started. I think other team members didn't want to work on it because they knew how thankless and open ended it would be to work on it, and unredeemable for quantifiable accomplishment credits. Because why else would it still be outstanding? I think someone more senior than me should be doing this architectural refactoring.
– amphibient
Oct 16 '13 at 21:20
1
If you're checking in revisions to vcs on a major project how is that not quantifiable? Just push/merge (if you're using git, replace with your vcs terminology otherwise) a couple times a day, then you'll have measured progress. Closing minor tickets that take <2 days to solve is not generally a responsibility of leads/seniors. Take it as a challenge and embrace the development of your skillset!
– Andrew Bartel
Oct 17 '13 at 1:14
i am saying that i am not checking such changes in because the project is analysis-heavy up front...
– amphibient
Oct 17 '13 at 1:18
1
Easily measured work assignment != Senior engineer work. That is for juniors and less experienced positions. How do I get paid at a senior engineer rate while only having junior engineer expectations would be a more accurate title for this question.
– IDrinkandIKnowThings
Nov 14 '13 at 1:32
add a comment |Â
I think they do. This issue predates my start date with the company. I think it should have been attended before I even started. I think other team members didn't want to work on it because they knew how thankless and open ended it would be to work on it, and unredeemable for quantifiable accomplishment credits. Because why else would it still be outstanding? I think someone more senior than me should be doing this architectural refactoring.
– amphibient
Oct 16 '13 at 21:20
1
If you're checking in revisions to vcs on a major project how is that not quantifiable? Just push/merge (if you're using git, replace with your vcs terminology otherwise) a couple times a day, then you'll have measured progress. Closing minor tickets that take <2 days to solve is not generally a responsibility of leads/seniors. Take it as a challenge and embrace the development of your skillset!
– Andrew Bartel
Oct 17 '13 at 1:14
i am saying that i am not checking such changes in because the project is analysis-heavy up front...
– amphibient
Oct 17 '13 at 1:18
1
Easily measured work assignment != Senior engineer work. That is for juniors and less experienced positions. How do I get paid at a senior engineer rate while only having junior engineer expectations would be a more accurate title for this question.
– IDrinkandIKnowThings
Nov 14 '13 at 1:32
I think they do. This issue predates my start date with the company. I think it should have been attended before I even started. I think other team members didn't want to work on it because they knew how thankless and open ended it would be to work on it, and unredeemable for quantifiable accomplishment credits. Because why else would it still be outstanding? I think someone more senior than me should be doing this architectural refactoring.
– amphibient
Oct 16 '13 at 21:20
I think they do. This issue predates my start date with the company. I think it should have been attended before I even started. I think other team members didn't want to work on it because they knew how thankless and open ended it would be to work on it, and unredeemable for quantifiable accomplishment credits. Because why else would it still be outstanding? I think someone more senior than me should be doing this architectural refactoring.
– amphibient
Oct 16 '13 at 21:20
1
1
If you're checking in revisions to vcs on a major project how is that not quantifiable? Just push/merge (if you're using git, replace with your vcs terminology otherwise) a couple times a day, then you'll have measured progress. Closing minor tickets that take <2 days to solve is not generally a responsibility of leads/seniors. Take it as a challenge and embrace the development of your skillset!
– Andrew Bartel
Oct 17 '13 at 1:14
If you're checking in revisions to vcs on a major project how is that not quantifiable? Just push/merge (if you're using git, replace with your vcs terminology otherwise) a couple times a day, then you'll have measured progress. Closing minor tickets that take <2 days to solve is not generally a responsibility of leads/seniors. Take it as a challenge and embrace the development of your skillset!
– Andrew Bartel
Oct 17 '13 at 1:14
i am saying that i am not checking such changes in because the project is analysis-heavy up front...
– amphibient
Oct 17 '13 at 1:18
i am saying that i am not checking such changes in because the project is analysis-heavy up front...
– amphibient
Oct 17 '13 at 1:18
1
1
Easily measured work assignment != Senior engineer work. That is for juniors and less experienced positions. How do I get paid at a senior engineer rate while only having junior engineer expectations would be a more accurate title for this question.
– IDrinkandIKnowThings
Nov 14 '13 at 1:32
Easily measured work assignment != Senior engineer work. That is for juniors and less experienced positions. How do I get paid at a senior engineer rate while only having junior engineer expectations would be a more accurate title for this question.
– IDrinkandIKnowThings
Nov 14 '13 at 1:32
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
14
down vote
While I don't object to you wanting a particular working style or assignment style, I would object to someone being called (and paid as) a senior anything if they refused to take on open-ended, high-stakes projects of indeterminate length. That's what seniors do. After all, if not you, who?
If you further clarified to me that your reason was you wanted to establish a strong performance record especially with management in other departments, I would be utterly furious, though I might not reveal that to you.
Be grateful you have been trusted with something big. Make a plan and have a way of tracking your progress against the plan. (This plan can include a number of points of closure such as "I have the regression tests I need as a safety net" and "I have replaced all the old X with new Y" to mesh well with your internal needs.) Report regularly as you make progress against the plan. Do a good job and you will have established your strong performance record. Ask instead to be spoonfed small easy jobs that everyone knows how to do, and you will not.
answered Oct 16 '13 at 21:03
Kate Gregory
105k40232334
RE: "spoonfed small (but not necessarily easy) jobs" -- I think that's a significant purpose of Agile and would not discount dissecting work into small atomic units
– amphibient
Oct 16 '13 at 21:07
5
but who does the dissecting? You, or your boss? For a senior I want to be able to say "make it so" and count on it getting done. Maybe not on schedule because maybe it can't be scheduled. But I don't want to hear "break that into pieces for me and have them put into Jira." Not from a senior.
– Kate Gregory
Oct 16 '13 at 21:09
i see that other developers are getting more defined work units. like "write this parser and here are the requirements"
– amphibient
Oct 16 '13 at 21:25
2
They won't man. I'm a lead, it's cool. If I see you busting your ass all day and not browsing facebook and come to me with reasonable questions I'm going to be pretty happy already. You were given this project because they trust you, embrace the challenge. If you have to, check your work product from the analysis you did into git for now unless your shop has a very specific policy about what can be committed. I bet it's worth saving and having versioned anyway.
– Andrew Bartel
Oct 17 '13 at 1:39
4
I have to say, the first paragraph here reflects my immediate reaction. If a senior software engineer doesn't want to take on tasks involving fundamental architectural change, then who will do those tasks? I'm afraid it comes across as if you want the responsibilities of a junior engineer with the title and salary of a senior.
– Carson63000
Oct 17 '13 at 1:48
 |Â
show 1 more comment
up vote
5
down vote
Executive Summary
- Reevaluate your Priorities
- Consider the Bigger Picture (What the Company Wants)
- Find the Middle-ground and Propose it
At the end of the day you were hired by the company with the expectation that you can do this sort of work. Anything that will demonstrate the inability to get that work done will be "damaging their perception of me".
Reevaluate your Priorities
You were hired by the company to do a specific job. Your skills and work description were discussed during the interview process, and you decided to work at this company as a result. Saying 2 months after this process that you actually want to do a totally different job than what you were hired for is going to be "damaging their perception of me" because it doesn't match the expectations they had when they agreed to hire you.
Look at your priorities. Right now it looks like you have them in this order:
- Do what you like doing
- Do the job you were hired for
Consider the Bigger Picture
At this stage of my tenure with the company, I am primarily interested in building an easily quantifiable performance record
Companies have limited resources to complete tasks of various importance to their success. With full knowledge of what tasks are required, and what tasks are most important for them as a company, they assigned you (the senior developer) this task over the others. They find it important, and that makes it a very easy quantifiable performance record:
- Can do tasks assigned for the good of the company
- Cannot do tasks assigned for the good of the company
Find the Middle-Ground
Once you understand that you were hired to do a job, and this job has to get finished, then you can work to find an alternative that will achieve the company's goals while respecting "my cognitive style and personality type". For instance, you could ask for the support of a developer actually interested in the big-picture stuff, and offer to work as a team to make sure his tasks get finished, and the big-picture stuff gets finished. You can hand off all the big-picture stuff to him, and take over part of his work load to have your check ins.
This doesn't mean the company will think highly of you (after all, you would basically be pawning off your job on someone paid less, which may give them hints about your relative importance to the company), but it will certainly be more effective than saying, "I don't want to do this work, give me totally different work in bite-sized chunks instead."
answered Oct 17 '13 at 2:02
jmac
19.4k763137
this is very good. however, i disagree with your somewhat condescending regard towards "bite-sized chunks" of work. i think it is the most reasonable initiation strategy for a new employee. a guy they hired less then 3 weeks ago already got to check stuff in and mark a ticket completed because the ticket was very well defined and closed ended, unlike my project, which is so open ended. they should give me well defined work for starters so i get a better sense of accomplishment rather than some "life on Mars" research
– amphibient
Oct 17 '13 at 2:16
1
You are hired as an expert (hence the 'senior' title). You have already been assigned similar things, "After a few assignments that I found to be reasonably scoped to my level of domain experience". They determined on the basis of those assignments that you should be the one to head this open-ended assignment. I am not being condescending regarding small individual tasks, I take issue with not doing what your employer expects of you.
– jmac
Oct 17 '13 at 2:25
RE: "not doing what your employer expects of you" -- if i were them, i would rather take feedback from the employee on what he is better suited to do at the given moment than have him spin wheels on a difficult problem. it's like when you're taking a test and can't answer a question, you move onto the next one to gain points on what you can finish at the given time. what people romantically regard as "perseverance" or "determination" can dig your grave if it never comes to fruition. you would have been better quitting and starting something else more suited for the moment
– amphibient
Oct 17 '13 at 2:41
if your question is, "How can I let my employer know I can't do the job I was hired for?" then that is a totally different story and a non-new employee version of this question. It isn't what your current question reads as (which says, "I work better on other stuff" not "I can't do the stuff I was assigned"). Could you edit your question to make it actually match your question?
– jmac
Oct 17 '13 at 2:46
1
I think that if you actually can't do the task you've been asked to do (can't find the end of the thread and start pulling), you have no business interviewing for senior developer positions. You've misrepresented yourself, and you should let your employer know and move on. If you want to rise to the challenge, I've given you some specific advice that should help you get to a solution.
– Amy Blankenship
Oct 18 '13 at 0:06
 |Â
show 2 more comments
up vote
3
down vote
I think that Kate has it right that you need to have a plan. However, I actually did a rewrite of an existing project, so you might find it useful to hear how I did it.
The first thing I did was write down all the tasks I could think of that needed to be done before we had a bare-bones usable version. I then wrote down estimates of how much time each would take and put them in a spreadsheet. Ultimately I also entered them in Asana so that anyone on the team could see where I was in the project, but I always referred back to the spreadsheet for time estimates, because obviously it's easier to total numbers in Excel.
Once I had the spreadsheet, I was able to send out progress reports and provide estimates on when various parts of the project would be finished. I worked like a dog to make sure I hit my estimates (not necessarily to the hour, but certainly if I said I would have x and y done in 8 workdays I would make sure I hit that even if I had to work 10-12 hour days). This gave me more internal motivation than I got from my boss, since at first there was no deadline and we were still able to use the old platform.
And I still have the spreadsheets, which I could use to update my resume--but a year after the fact, the benefits of the platform are more interesting than the list of things I did to get there.
One thing you'll probably find in the course of writing all this down is that you don't actually have a clear idea of everything that needs to be done. Probably a big reason why no one wants to work on this is that their gut is telling them that they don't quite know what to do. Be the guy who can actually solve this by surfacing these issues and figuring out the requirements.
One of the tasks that clearly should be on your list of things to accomplish (but clearly isn't) is to get the project into version control. There's no reason you can't check in each piece as you revise it--to a branch, if nothing else.
BTW, it's possible you've put yourself on the "fire when practical" list by acting like a prima donna. I don't think I've ever had a boss who would even think to look at checkins to see who to fire--much as sometime I have privately felt that would be a good idea ;).
answered Oct 16 '13 at 23:40
Amy Blankenship
7,13711836
thanks but your approach does not really apply to my situation
– amphibient
Oct 17 '13 at 0:42
1
In what way? You can't break your task into smaller units of work and tackle those? That's what refactoring is.
– Amy Blankenship
Oct 18 '13 at 0:02
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
14
down vote
While I don't object to you wanting a particular working style or assignment style, I would object to someone being called (and paid as) a senior anything if they refused to take on open-ended, high-stakes projects of indeterminate length. That's what seniors do. After all, if not you, who?
If you further clarified to me that your reason was you wanted to establish a strong performance record especially with management in other departments, I would be utterly furious, though I might not reveal that to you.
Be grateful you have been trusted with something big. Make a plan and have a way of tracking your progress against the plan. (This plan can include a number of points of closure such as "I have the regression tests I need as a safety net" and "I have replaced all the old X with new Y" to mesh well with your internal needs.) Report regularly as you make progress against the plan. Do a good job and you will have established your strong performance record. Ask instead to be spoonfed small easy jobs that everyone knows how to do, and you will not.
answered Oct 16 '13 at 21:03
Kate Gregory
105k40232334
RE: "spoonfed small (but not necessarily easy) jobs" -- I think that's a significant purpose of Agile and would not discount dissecting work into small atomic units
– amphibient
Oct 16 '13 at 21:07
5
but who does the dissecting? You, or your boss? For a senior I want to be able to say "make it so" and count on it getting done. Maybe not on schedule because maybe it can't be scheduled. But I don't want to hear "break that into pieces for me and have them put into Jira." Not from a senior.
– Kate Gregory
Oct 16 '13 at 21:09
i see that other developers are getting more defined work units. like "write this parser and here are the requirements"
– amphibient
Oct 16 '13 at 21:25
2
They won't man. I'm a lead, it's cool. If I see you busting your ass all day and not browsing facebook and come to me with reasonable questions I'm going to be pretty happy already. You were given this project because they trust you, embrace the challenge. If you have to, check your work product from the analysis you did into git for now unless your shop has a very specific policy about what can be committed. I bet it's worth saving and having versioned anyway.
– Andrew Bartel
Oct 17 '13 at 1:39
4
I have to say, the first paragraph here reflects my immediate reaction. If a senior software engineer doesn't want to take on tasks involving fundamental architectural change, then who will do those tasks? I'm afraid it comes across as if you want the responsibilities of a junior engineer with the title and salary of a senior.
– Carson63000
Oct 17 '13 at 1:48
 |Â
show 1 more comment
up vote
14
down vote
While I don't object to you wanting a particular working style or assignment style, I would object to someone being called (and paid as) a senior anything if they refused to take on open-ended, high-stakes projects of indeterminate length. That's what seniors do. After all, if not you, who?
If you further clarified to me that your reason was you wanted to establish a strong performance record especially with management in other departments, I would be utterly furious, though I might not reveal that to you.
Be grateful you have been trusted with something big. Make a plan and have a way of tracking your progress against the plan. (This plan can include a number of points of closure such as "I have the regression tests I need as a safety net" and "I have replaced all the old X with new Y" to mesh well with your internal needs.) Report regularly as you make progress against the plan. Do a good job and you will have established your strong performance record. Ask instead to be spoonfed small easy jobs that everyone knows how to do, and you will not.
answered Oct 16 '13 at 21:03
Kate Gregory
105k40232334
RE: "spoonfed small (but not necessarily easy) jobs" -- I think that's a significant purpose of Agile and would not discount dissecting work into small atomic units
– amphibient
Oct 16 '13 at 21:07
5
but who does the dissecting? You, or your boss? For a senior I want to be able to say "make it so" and count on it getting done. Maybe not on schedule because maybe it can't be scheduled. But I don't want to hear "break that into pieces for me and have them put into Jira." Not from a senior.
– Kate Gregory
Oct 16 '13 at 21:09
i see that other developers are getting more defined work units. like "write this parser and here are the requirements"
– amphibient
Oct 16 '13 at 21:25
2
They won't man. I'm a lead, it's cool. If I see you busting your ass all day and not browsing facebook and come to me with reasonable questions I'm going to be pretty happy already. You were given this project because they trust you, embrace the challenge. If you have to, check your work product from the analysis you did into git for now unless your shop has a very specific policy about what can be committed. I bet it's worth saving and having versioned anyway.
– Andrew Bartel
Oct 17 '13 at 1:39
4
I have to say, the first paragraph here reflects my immediate reaction. If a senior software engineer doesn't want to take on tasks involving fundamental architectural change, then who will do those tasks? I'm afraid it comes across as if you want the responsibilities of a junior engineer with the title and salary of a senior.
– Carson63000
Oct 17 '13 at 1:48
 |Â
show 1 more comment
up vote
14
down vote
up vote
14
down vote
While I don't object to you wanting a particular working style or assignment style, I would object to someone being called (and paid as) a senior anything if they refused to take on open-ended, high-stakes projects of indeterminate length. That's what seniors do. After all, if not you, who?
If you further clarified to me that your reason was you wanted to establish a strong performance record especially with management in other departments, I would be utterly furious, though I might not reveal that to you.
Be grateful you have been trusted with something big. Make a plan and have a way of tracking your progress against the plan. (This plan can include a number of points of closure such as "I have the regression tests I need as a safety net" and "I have replaced all the old X with new Y" to mesh well with your internal needs.) Report regularly as you make progress against the plan. Do a good job and you will have established your strong performance record. Ask instead to be spoonfed small easy jobs that everyone knows how to do, and you will not.
answered Oct 16 '13 at 21:03
Kate Gregory
105k40232334
While I don't object to you wanting a particular working style or assignment style, I would object to someone being called (and paid as) a senior anything if they refused to take on open-ended, high-stakes projects of indeterminate length. That's what seniors do. After all, if not you, who?
If you further clarified to me that your reason was you wanted to establish a strong performance record especially with management in other departments, I would be utterly furious, though I might not reveal that to you.
Be grateful you have been trusted with something big. Make a plan and have a way of tracking your progress against the plan. (This plan can include a number of points of closure such as "I have the regression tests I need as a safety net" and "I have replaced all the old X with new Y" to mesh well with your internal needs.) Report regularly as you make progress against the plan. Do a good job and you will have established your strong performance record. Ask instead to be spoonfed small easy jobs that everyone knows how to do, and you will not.
answered Oct 16 '13 at 21:03
Kate Gregory
105k40232334
answered Oct 16 '13 at 21:03
Kate Gregory
105k40232334
answered Oct 16 '13 at 21:03
Kate Gregory
105k40232334
answered Oct 16 '13 at 21:03
Kate Gregory
105k40232334
105k40232334
RE: "spoonfed small (but not necessarily easy) jobs" -- I think that's a significant purpose of Agile and would not discount dissecting work into small atomic units
– amphibient
Oct 16 '13 at 21:07
5
but who does the dissecting? You, or your boss? For a senior I want to be able to say "make it so" and count on it getting done. Maybe not on schedule because maybe it can't be scheduled. But I don't want to hear "break that into pieces for me and have them put into Jira." Not from a senior.
– Kate Gregory
Oct 16 '13 at 21:09
i see that other developers are getting more defined work units. like "write this parser and here are the requirements"
– amphibient
Oct 16 '13 at 21:25
2
They won't man. I'm a lead, it's cool. If I see you busting your ass all day and not browsing facebook and come to me with reasonable questions I'm going to be pretty happy already. You were given this project because they trust you, embrace the challenge. If you have to, check your work product from the analysis you did into git for now unless your shop has a very specific policy about what can be committed. I bet it's worth saving and having versioned anyway.
– Andrew Bartel
Oct 17 '13 at 1:39
4
I have to say, the first paragraph here reflects my immediate reaction. If a senior software engineer doesn't want to take on tasks involving fundamental architectural change, then who will do those tasks? I'm afraid it comes across as if you want the responsibilities of a junior engineer with the title and salary of a senior.
– Carson63000
Oct 17 '13 at 1:48
 |Â
show 1 more comment
RE: "spoonfed small (but not necessarily easy) jobs" -- I think that's a significant purpose of Agile and would not discount dissecting work into small atomic units
– amphibient
Oct 16 '13 at 21:07
5
but who does the dissecting? You, or your boss? For a senior I want to be able to say "make it so" and count on it getting done. Maybe not on schedule because maybe it can't be scheduled. But I don't want to hear "break that into pieces for me and have them put into Jira." Not from a senior.
– Kate Gregory
Oct 16 '13 at 21:09
i see that other developers are getting more defined work units. like "write this parser and here are the requirements"
– amphibient
Oct 16 '13 at 21:25
2
They won't man. I'm a lead, it's cool. If I see you busting your ass all day and not browsing facebook and come to me with reasonable questions I'm going to be pretty happy already. You were given this project because they trust you, embrace the challenge. If you have to, check your work product from the analysis you did into git for now unless your shop has a very specific policy about what can be committed. I bet it's worth saving and having versioned anyway.
– Andrew Bartel
Oct 17 '13 at 1:39
4
I have to say, the first paragraph here reflects my immediate reaction. If a senior software engineer doesn't want to take on tasks involving fundamental architectural change, then who will do those tasks? I'm afraid it comes across as if you want the responsibilities of a junior engineer with the title and salary of a senior.
– Carson63000
Oct 17 '13 at 1:48
RE: "spoonfed small (but not necessarily easy) jobs" -- I think that's a significant purpose of Agile and would not discount dissecting work into small atomic units
– amphibient
Oct 16 '13 at 21:07
RE: "spoonfed small (but not necessarily easy) jobs" -- I think that's a significant purpose of Agile and would not discount dissecting work into small atomic units
– amphibient
Oct 16 '13 at 21:07
5
5
but who does the dissecting? You, or your boss? For a senior I want to be able to say "make it so" and count on it getting done. Maybe not on schedule because maybe it can't be scheduled. But I don't want to hear "break that into pieces for me and have them put into Jira." Not from a senior.
– Kate Gregory
Oct 16 '13 at 21:09
but who does the dissecting? You, or your boss? For a senior I want to be able to say "make it so" and count on it getting done. Maybe not on schedule because maybe it can't be scheduled. But I don't want to hear "break that into pieces for me and have them put into Jira." Not from a senior.
– Kate Gregory
Oct 16 '13 at 21:09
i see that other developers are getting more defined work units. like "write this parser and here are the requirements"
– amphibient
Oct 16 '13 at 21:25
i see that other developers are getting more defined work units. like "write this parser and here are the requirements"
– amphibient
Oct 16 '13 at 21:25
2
2
They won't man. I'm a lead, it's cool. If I see you busting your ass all day and not browsing facebook and come to me with reasonable questions I'm going to be pretty happy already. You were given this project because they trust you, embrace the challenge. If you have to, check your work product from the analysis you did into git for now unless your shop has a very specific policy about what can be committed. I bet it's worth saving and having versioned anyway.
– Andrew Bartel
Oct 17 '13 at 1:39
They won't man. I'm a lead, it's cool. If I see you busting your ass all day and not browsing facebook and come to me with reasonable questions I'm going to be pretty happy already. You were given this project because they trust you, embrace the challenge. If you have to, check your work product from the analysis you did into git for now unless your shop has a very specific policy about what can be committed. I bet it's worth saving and having versioned anyway.
– Andrew Bartel
Oct 17 '13 at 1:39
4
4
I have to say, the first paragraph here reflects my immediate reaction. If a senior software engineer doesn't want to take on tasks involving fundamental architectural change, then who will do those tasks? I'm afraid it comes across as if you want the responsibilities of a junior engineer with the title and salary of a senior.
– Carson63000
Oct 17 '13 at 1:48
I have to say, the first paragraph here reflects my immediate reaction. If a senior software engineer doesn't want to take on tasks involving fundamental architectural change, then who will do those tasks? I'm afraid it comes across as if you want the responsibilities of a junior engineer with the title and salary of a senior.
– Carson63000
Oct 17 '13 at 1:48
 |Â
show 1 more comment
up vote
5
down vote
Executive Summary
- Reevaluate your Priorities
- Consider the Bigger Picture (What the Company Wants)
- Find the Middle-ground and Propose it
At the end of the day you were hired by the company with the expectation that you can do this sort of work. Anything that will demonstrate the inability to get that work done will be "damaging their perception of me".
Reevaluate your Priorities
You were hired by the company to do a specific job. Your skills and work description were discussed during the interview process, and you decided to work at this company as a result. Saying 2 months after this process that you actually want to do a totally different job than what you were hired for is going to be "damaging their perception of me" because it doesn't match the expectations they had when they agreed to hire you.
Look at your priorities. Right now it looks like you have them in this order:
- Do what you like doing
- Do the job you were hired for
Consider the Bigger Picture
At this stage of my tenure with the company, I am primarily interested in building an easily quantifiable performance record
Companies have limited resources to complete tasks of various importance to their success. With full knowledge of what tasks are required, and what tasks are most important for them as a company, they assigned you (the senior developer) this task over the others. They find it important, and that makes it a very easy quantifiable performance record:
- Can do tasks assigned for the good of the company
- Cannot do tasks assigned for the good of the company
Find the Middle-Ground
Once you understand that you were hired to do a job, and this job has to get finished, then you can work to find an alternative that will achieve the company's goals while respecting "my cognitive style and personality type". For instance, you could ask for the support of a developer actually interested in the big-picture stuff, and offer to work as a team to make sure his tasks get finished, and the big-picture stuff gets finished. You can hand off all the big-picture stuff to him, and take over part of his work load to have your check ins.
This doesn't mean the company will think highly of you (after all, you would basically be pawning off your job on someone paid less, which may give them hints about your relative importance to the company), but it will certainly be more effective than saying, "I don't want to do this work, give me totally different work in bite-sized chunks instead."
answered Oct 17 '13 at 2:02
jmac
19.4k763137
this is very good. however, i disagree with your somewhat condescending regard towards "bite-sized chunks" of work. i think it is the most reasonable initiation strategy for a new employee. a guy they hired less then 3 weeks ago already got to check stuff in and mark a ticket completed because the ticket was very well defined and closed ended, unlike my project, which is so open ended. they should give me well defined work for starters so i get a better sense of accomplishment rather than some "life on Mars" research
– amphibient
Oct 17 '13 at 2:16
1
You are hired as an expert (hence the 'senior' title). You have already been assigned similar things, "After a few assignments that I found to be reasonably scoped to my level of domain experience". They determined on the basis of those assignments that you should be the one to head this open-ended assignment. I am not being condescending regarding small individual tasks, I take issue with not doing what your employer expects of you.
– jmac
Oct 17 '13 at 2:25
RE: "not doing what your employer expects of you" -- if i were them, i would rather take feedback from the employee on what he is better suited to do at the given moment than have him spin wheels on a difficult problem. it's like when you're taking a test and can't answer a question, you move onto the next one to gain points on what you can finish at the given time. what people romantically regard as "perseverance" or "determination" can dig your grave if it never comes to fruition. you would have been better quitting and starting something else more suited for the moment
– amphibient
Oct 17 '13 at 2:41
if your question is, "How can I let my employer know I can't do the job I was hired for?" then that is a totally different story and a non-new employee version of this question. It isn't what your current question reads as (which says, "I work better on other stuff" not "I can't do the stuff I was assigned"). Could you edit your question to make it actually match your question?
– jmac
Oct 17 '13 at 2:46
1
I think that if you actually can't do the task you've been asked to do (can't find the end of the thread and start pulling), you have no business interviewing for senior developer positions. You've misrepresented yourself, and you should let your employer know and move on. If you want to rise to the challenge, I've given you some specific advice that should help you get to a solution.
– Amy Blankenship
Oct 18 '13 at 0:06
 |Â
show 2 more comments
up vote
5
down vote
Executive Summary
- Reevaluate your Priorities
- Consider the Bigger Picture (What the Company Wants)
- Find the Middle-ground and Propose it
At the end of the day you were hired by the company with the expectation that you can do this sort of work. Anything that will demonstrate the inability to get that work done will be "damaging their perception of me".
Reevaluate your Priorities
You were hired by the company to do a specific job. Your skills and work description were discussed during the interview process, and you decided to work at this company as a result. Saying 2 months after this process that you actually want to do a totally different job than what you were hired for is going to be "damaging their perception of me" because it doesn't match the expectations they had when they agreed to hire you.
Look at your priorities. Right now it looks like you have them in this order:
- Do what you like doing
- Do the job you were hired for
Consider the Bigger Picture
At this stage of my tenure with the company, I am primarily interested in building an easily quantifiable performance record
Companies have limited resources to complete tasks of various importance to their success. With full knowledge of what tasks are required, and what tasks are most important for them as a company, they assigned you (the senior developer) this task over the others. They find it important, and that makes it a very easy quantifiable performance record:
- Can do tasks assigned for the good of the company
- Cannot do tasks assigned for the good of the company
Find the Middle-Ground
Once you understand that you were hired to do a job, and this job has to get finished, then you can work to find an alternative that will achieve the company's goals while respecting "my cognitive style and personality type". For instance, you could ask for the support of a developer actually interested in the big-picture stuff, and offer to work as a team to make sure his tasks get finished, and the big-picture stuff gets finished. You can hand off all the big-picture stuff to him, and take over part of his work load to have your check ins.
This doesn't mean the company will think highly of you (after all, you would basically be pawning off your job on someone paid less, which may give them hints about your relative importance to the company), but it will certainly be more effective than saying, "I don't want to do this work, give me totally different work in bite-sized chunks instead."
answered Oct 17 '13 at 2:02
jmac
19.4k763137
this is very good. however, i disagree with your somewhat condescending regard towards "bite-sized chunks" of work. i think it is the most reasonable initiation strategy for a new employee. a guy they hired less then 3 weeks ago already got to check stuff in and mark a ticket completed because the ticket was very well defined and closed ended, unlike my project, which is so open ended. they should give me well defined work for starters so i get a better sense of accomplishment rather than some "life on Mars" research
– amphibient
Oct 17 '13 at 2:16
1
You are hired as an expert (hence the 'senior' title). You have already been assigned similar things, "After a few assignments that I found to be reasonably scoped to my level of domain experience". They determined on the basis of those assignments that you should be the one to head this open-ended assignment. I am not being condescending regarding small individual tasks, I take issue with not doing what your employer expects of you.
– jmac
Oct 17 '13 at 2:25
RE: "not doing what your employer expects of you" -- if i were them, i would rather take feedback from the employee on what he is better suited to do at the given moment than have him spin wheels on a difficult problem. it's like when you're taking a test and can't answer a question, you move onto the next one to gain points on what you can finish at the given time. what people romantically regard as "perseverance" or "determination" can dig your grave if it never comes to fruition. you would have been better quitting and starting something else more suited for the moment
– amphibient
Oct 17 '13 at 2:41
if your question is, "How can I let my employer know I can't do the job I was hired for?" then that is a totally different story and a non-new employee version of this question. It isn't what your current question reads as (which says, "I work better on other stuff" not "I can't do the stuff I was assigned"). Could you edit your question to make it actually match your question?
– jmac
Oct 17 '13 at 2:46
1
I think that if you actually can't do the task you've been asked to do (can't find the end of the thread and start pulling), you have no business interviewing for senior developer positions. You've misrepresented yourself, and you should let your employer know and move on. If you want to rise to the challenge, I've given you some specific advice that should help you get to a solution.
– Amy Blankenship
Oct 18 '13 at 0:06
 |Â
show 2 more comments
up vote
5
down vote
up vote
5
down vote
Executive Summary
- Reevaluate your Priorities
- Consider the Bigger Picture (What the Company Wants)
- Find the Middle-ground and Propose it
At the end of the day you were hired by the company with the expectation that you can do this sort of work. Anything that will demonstrate the inability to get that work done will be "damaging their perception of me".
Reevaluate your Priorities
You were hired by the company to do a specific job. Your skills and work description were discussed during the interview process, and you decided to work at this company as a result. Saying 2 months after this process that you actually want to do a totally different job than what you were hired for is going to be "damaging their perception of me" because it doesn't match the expectations they had when they agreed to hire you.
Look at your priorities. Right now it looks like you have them in this order:
- Do what you like doing
- Do the job you were hired for
Consider the Bigger Picture
At this stage of my tenure with the company, I am primarily interested in building an easily quantifiable performance record
Companies have limited resources to complete tasks of various importance to their success. With full knowledge of what tasks are required, and what tasks are most important for them as a company, they assigned you (the senior developer) this task over the others. They find it important, and that makes it a very easy quantifiable performance record:
- Can do tasks assigned for the good of the company
- Cannot do tasks assigned for the good of the company
Find the Middle-Ground
Once you understand that you were hired to do a job, and this job has to get finished, then you can work to find an alternative that will achieve the company's goals while respecting "my cognitive style and personality type". For instance, you could ask for the support of a developer actually interested in the big-picture stuff, and offer to work as a team to make sure his tasks get finished, and the big-picture stuff gets finished. You can hand off all the big-picture stuff to him, and take over part of his work load to have your check ins.
This doesn't mean the company will think highly of you (after all, you would basically be pawning off your job on someone paid less, which may give them hints about your relative importance to the company), but it will certainly be more effective than saying, "I don't want to do this work, give me totally different work in bite-sized chunks instead."
answered Oct 17 '13 at 2:02
jmac
19.4k763137
Executive Summary
- Reevaluate your Priorities
- Consider the Bigger Picture (What the Company Wants)
- Find the Middle-ground and Propose it
At the end of the day you were hired by the company with the expectation that you can do this sort of work. Anything that will demonstrate the inability to get that work done will be "damaging their perception of me".
Reevaluate your Priorities
You were hired by the company to do a specific job. Your skills and work description were discussed during the interview process, and you decided to work at this company as a result. Saying 2 months after this process that you actually want to do a totally different job than what you were hired for is going to be "damaging their perception of me" because it doesn't match the expectations they had when they agreed to hire you.
Look at your priorities. Right now it looks like you have them in this order:
- Do what you like doing
- Do the job you were hired for
Consider the Bigger Picture
At this stage of my tenure with the company, I am primarily interested in building an easily quantifiable performance record
Companies have limited resources to complete tasks of various importance to their success. With full knowledge of what tasks are required, and what tasks are most important for them as a company, they assigned you (the senior developer) this task over the others. They find it important, and that makes it a very easy quantifiable performance record:
- Can do tasks assigned for the good of the company
- Cannot do tasks assigned for the good of the company
Find the Middle-Ground
Once you understand that you were hired to do a job, and this job has to get finished, then you can work to find an alternative that will achieve the company's goals while respecting "my cognitive style and personality type". For instance, you could ask for the support of a developer actually interested in the big-picture stuff, and offer to work as a team to make sure his tasks get finished, and the big-picture stuff gets finished. You can hand off all the big-picture stuff to him, and take over part of his work load to have your check ins.
This doesn't mean the company will think highly of you (after all, you would basically be pawning off your job on someone paid less, which may give them hints about your relative importance to the company), but it will certainly be more effective than saying, "I don't want to do this work, give me totally different work in bite-sized chunks instead."
answered Oct 17 '13 at 2:02
jmac
19.4k763137
answered Oct 17 '13 at 2:02
jmac
19.4k763137
answered Oct 17 '13 at 2:02
jmac
19.4k763137
answered Oct 17 '13 at 2:02
jmac
19.4k763137
19.4k763137
this is very good. however, i disagree with your somewhat condescending regard towards "bite-sized chunks" of work. i think it is the most reasonable initiation strategy for a new employee. a guy they hired less then 3 weeks ago already got to check stuff in and mark a ticket completed because the ticket was very well defined and closed ended, unlike my project, which is so open ended. they should give me well defined work for starters so i get a better sense of accomplishment rather than some "life on Mars" research
– amphibient
Oct 17 '13 at 2:16
1
You are hired as an expert (hence the 'senior' title). You have already been assigned similar things, "After a few assignments that I found to be reasonably scoped to my level of domain experience". They determined on the basis of those assignments that you should be the one to head this open-ended assignment. I am not being condescending regarding small individual tasks, I take issue with not doing what your employer expects of you.
– jmac
Oct 17 '13 at 2:25
RE: "not doing what your employer expects of you" -- if i were them, i would rather take feedback from the employee on what he is better suited to do at the given moment than have him spin wheels on a difficult problem. it's like when you're taking a test and can't answer a question, you move onto the next one to gain points on what you can finish at the given time. what people romantically regard as "perseverance" or "determination" can dig your grave if it never comes to fruition. you would have been better quitting and starting something else more suited for the moment
– amphibient
Oct 17 '13 at 2:41
if your question is, "How can I let my employer know I can't do the job I was hired for?" then that is a totally different story and a non-new employee version of this question. It isn't what your current question reads as (which says, "I work better on other stuff" not "I can't do the stuff I was assigned"). Could you edit your question to make it actually match your question?
– jmac
Oct 17 '13 at 2:46
1
I think that if you actually can't do the task you've been asked to do (can't find the end of the thread and start pulling), you have no business interviewing for senior developer positions. You've misrepresented yourself, and you should let your employer know and move on. If you want to rise to the challenge, I've given you some specific advice that should help you get to a solution.
– Amy Blankenship
Oct 18 '13 at 0:06
 |Â
show 2 more comments
this is very good. however, i disagree with your somewhat condescending regard towards "bite-sized chunks" of work. i think it is the most reasonable initiation strategy for a new employee. a guy they hired less then 3 weeks ago already got to check stuff in and mark a ticket completed because the ticket was very well defined and closed ended, unlike my project, which is so open ended. they should give me well defined work for starters so i get a better sense of accomplishment rather than some "life on Mars" research
– amphibient
Oct 17 '13 at 2:16
1
You are hired as an expert (hence the 'senior' title). You have already been assigned similar things, "After a few assignments that I found to be reasonably scoped to my level of domain experience". They determined on the basis of those assignments that you should be the one to head this open-ended assignment. I am not being condescending regarding small individual tasks, I take issue with not doing what your employer expects of you.
– jmac
Oct 17 '13 at 2:25
RE: "not doing what your employer expects of you" -- if i were them, i would rather take feedback from the employee on what he is better suited to do at the given moment than have him spin wheels on a difficult problem. it's like when you're taking a test and can't answer a question, you move onto the next one to gain points on what you can finish at the given time. what people romantically regard as "perseverance" or "determination" can dig your grave if it never comes to fruition. you would have been better quitting and starting something else more suited for the moment
– amphibient
Oct 17 '13 at 2:41
if your question is, "How can I let my employer know I can't do the job I was hired for?" then that is a totally different story and a non-new employee version of this question. It isn't what your current question reads as (which says, "I work better on other stuff" not "I can't do the stuff I was assigned"). Could you edit your question to make it actually match your question?
– jmac
Oct 17 '13 at 2:46
1
I think that if you actually can't do the task you've been asked to do (can't find the end of the thread and start pulling), you have no business interviewing for senior developer positions. You've misrepresented yourself, and you should let your employer know and move on. If you want to rise to the challenge, I've given you some specific advice that should help you get to a solution.
– Amy Blankenship
Oct 18 '13 at 0:06
this is very good. however, i disagree with your somewhat condescending regard towards "bite-sized chunks" of work. i think it is the most reasonable initiation strategy for a new employee. a guy they hired less then 3 weeks ago already got to check stuff in and mark a ticket completed because the ticket was very well defined and closed ended, unlike my project, which is so open ended. they should give me well defined work for starters so i get a better sense of accomplishment rather than some "life on Mars" research
– amphibient
Oct 17 '13 at 2:16
this is very good. however, i disagree with your somewhat condescending regard towards "bite-sized chunks" of work. i think it is the most reasonable initiation strategy for a new employee. a guy they hired less then 3 weeks ago already got to check stuff in and mark a ticket completed because the ticket was very well defined and closed ended, unlike my project, which is so open ended. they should give me well defined work for starters so i get a better sense of accomplishment rather than some "life on Mars" research
– amphibient
Oct 17 '13 at 2:16
1
1
You are hired as an expert (hence the 'senior' title). You have already been assigned similar things, "After a few assignments that I found to be reasonably scoped to my level of domain experience". They determined on the basis of those assignments that you should be the one to head this open-ended assignment. I am not being condescending regarding small individual tasks, I take issue with not doing what your employer expects of you.
– jmac
Oct 17 '13 at 2:25
You are hired as an expert (hence the 'senior' title). You have already been assigned similar things, "After a few assignments that I found to be reasonably scoped to my level of domain experience". They determined on the basis of those assignments that you should be the one to head this open-ended assignment. I am not being condescending regarding small individual tasks, I take issue with not doing what your employer expects of you.
– jmac
Oct 17 '13 at 2:25
RE: "not doing what your employer expects of you" -- if i were them, i would rather take feedback from the employee on what he is better suited to do at the given moment than have him spin wheels on a difficult problem. it's like when you're taking a test and can't answer a question, you move onto the next one to gain points on what you can finish at the given time. what people romantically regard as "perseverance" or "determination" can dig your grave if it never comes to fruition. you would have been better quitting and starting something else more suited for the moment
– amphibient
Oct 17 '13 at 2:41
RE: "not doing what your employer expects of you" -- if i were them, i would rather take feedback from the employee on what he is better suited to do at the given moment than have him spin wheels on a difficult problem. it's like when you're taking a test and can't answer a question, you move onto the next one to gain points on what you can finish at the given time. what people romantically regard as "perseverance" or "determination" can dig your grave if it never comes to fruition. you would have been better quitting and starting something else more suited for the moment
– amphibient
Oct 17 '13 at 2:41
if your question is, "How can I let my employer know I can't do the job I was hired for?" then that is a totally different story and a non-new employee version of this question. It isn't what your current question reads as (which says, "I work better on other stuff" not "I can't do the stuff I was assigned"). Could you edit your question to make it actually match your question?
– jmac
Oct 17 '13 at 2:46
if your question is, "How can I let my employer know I can't do the job I was hired for?" then that is a totally different story and a non-new employee version of this question. It isn't what your current question reads as (which says, "I work better on other stuff" not "I can't do the stuff I was assigned"). Could you edit your question to make it actually match your question?
– jmac
Oct 17 '13 at 2:46
1
1
I think that if you actually can't do the task you've been asked to do (can't find the end of the thread and start pulling), you have no business interviewing for senior developer positions. You've misrepresented yourself, and you should let your employer know and move on. If you want to rise to the challenge, I've given you some specific advice that should help you get to a solution.
– Amy Blankenship
Oct 18 '13 at 0:06
I think that if you actually can't do the task you've been asked to do (can't find the end of the thread and start pulling), you have no business interviewing for senior developer positions. You've misrepresented yourself, and you should let your employer know and move on. If you want to rise to the challenge, I've given you some specific advice that should help you get to a solution.
– Amy Blankenship
Oct 18 '13 at 0:06
 |Â
show 2 more comments
up vote
3
down vote
I think that Kate has it right that you need to have a plan. However, I actually did a rewrite of an existing project, so you might find it useful to hear how I did it.
The first thing I did was write down all the tasks I could think of that needed to be done before we had a bare-bones usable version. I then wrote down estimates of how much time each would take and put them in a spreadsheet. Ultimately I also entered them in Asana so that anyone on the team could see where I was in the project, but I always referred back to the spreadsheet for time estimates, because obviously it's easier to total numbers in Excel.
Once I had the spreadsheet, I was able to send out progress reports and provide estimates on when various parts of the project would be finished. I worked like a dog to make sure I hit my estimates (not necessarily to the hour, but certainly if I said I would have x and y done in 8 workdays I would make sure I hit that even if I had to work 10-12 hour days). This gave me more internal motivation than I got from my boss, since at first there was no deadline and we were still able to use the old platform.
And I still have the spreadsheets, which I could use to update my resume--but a year after the fact, the benefits of the platform are more interesting than the list of things I did to get there.
One thing you'll probably find in the course of writing all this down is that you don't actually have a clear idea of everything that needs to be done. Probably a big reason why no one wants to work on this is that their gut is telling them that they don't quite know what to do. Be the guy who can actually solve this by surfacing these issues and figuring out the requirements.
One of the tasks that clearly should be on your list of things to accomplish (but clearly isn't) is to get the project into version control. There's no reason you can't check in each piece as you revise it--to a branch, if nothing else.
BTW, it's possible you've put yourself on the "fire when practical" list by acting like a prima donna. I don't think I've ever had a boss who would even think to look at checkins to see who to fire--much as sometime I have privately felt that would be a good idea ;).
answered Oct 16 '13 at 23:40
Amy Blankenship
7,13711836
thanks but your approach does not really apply to my situation
– amphibient
Oct 17 '13 at 0:42
1
In what way? You can't break your task into smaller units of work and tackle those? That's what refactoring is.
– Amy Blankenship
Oct 18 '13 at 0:02
add a comment |Â
up vote
3
down vote
I think that Kate has it right that you need to have a plan. However, I actually did a rewrite of an existing project, so you might find it useful to hear how I did it.
The first thing I did was write down all the tasks I could think of that needed to be done before we had a bare-bones usable version. I then wrote down estimates of how much time each would take and put them in a spreadsheet. Ultimately I also entered them in Asana so that anyone on the team could see where I was in the project, but I always referred back to the spreadsheet for time estimates, because obviously it's easier to total numbers in Excel.
Once I had the spreadsheet, I was able to send out progress reports and provide estimates on when various parts of the project would be finished. I worked like a dog to make sure I hit my estimates (not necessarily to the hour, but certainly if I said I would have x and y done in 8 workdays I would make sure I hit that even if I had to work 10-12 hour days). This gave me more internal motivation than I got from my boss, since at first there was no deadline and we were still able to use the old platform.
And I still have the spreadsheets, which I could use to update my resume--but a year after the fact, the benefits of the platform are more interesting than the list of things I did to get there.
One thing you'll probably find in the course of writing all this down is that you don't actually have a clear idea of everything that needs to be done. Probably a big reason why no one wants to work on this is that their gut is telling them that they don't quite know what to do. Be the guy who can actually solve this by surfacing these issues and figuring out the requirements.
One of the tasks that clearly should be on your list of things to accomplish (but clearly isn't) is to get the project into version control. There's no reason you can't check in each piece as you revise it--to a branch, if nothing else.
BTW, it's possible you've put yourself on the "fire when practical" list by acting like a prima donna. I don't think I've ever had a boss who would even think to look at checkins to see who to fire--much as sometime I have privately felt that would be a good idea ;).
answered Oct 16 '13 at 23:40
Amy Blankenship
7,13711836
thanks but your approach does not really apply to my situation
– amphibient
Oct 17 '13 at 0:42
1
In what way? You can't break your task into smaller units of work and tackle those? That's what refactoring is.
– Amy Blankenship
Oct 18 '13 at 0:02
add a comment |Â
up vote
3
down vote
up vote
3
down vote
I think that Kate has it right that you need to have a plan. However, I actually did a rewrite of an existing project, so you might find it useful to hear how I did it.
The first thing I did was write down all the tasks I could think of that needed to be done before we had a bare-bones usable version. I then wrote down estimates of how much time each would take and put them in a spreadsheet. Ultimately I also entered them in Asana so that anyone on the team could see where I was in the project, but I always referred back to the spreadsheet for time estimates, because obviously it's easier to total numbers in Excel.
Once I had the spreadsheet, I was able to send out progress reports and provide estimates on when various parts of the project would be finished. I worked like a dog to make sure I hit my estimates (not necessarily to the hour, but certainly if I said I would have x and y done in 8 workdays I would make sure I hit that even if I had to work 10-12 hour days). This gave me more internal motivation than I got from my boss, since at first there was no deadline and we were still able to use the old platform.
And I still have the spreadsheets, which I could use to update my resume--but a year after the fact, the benefits of the platform are more interesting than the list of things I did to get there.
One thing you'll probably find in the course of writing all this down is that you don't actually have a clear idea of everything that needs to be done. Probably a big reason why no one wants to work on this is that their gut is telling them that they don't quite know what to do. Be the guy who can actually solve this by surfacing these issues and figuring out the requirements.
One of the tasks that clearly should be on your list of things to accomplish (but clearly isn't) is to get the project into version control. There's no reason you can't check in each piece as you revise it--to a branch, if nothing else.
BTW, it's possible you've put yourself on the "fire when practical" list by acting like a prima donna. I don't think I've ever had a boss who would even think to look at checkins to see who to fire--much as sometime I have privately felt that would be a good idea ;).
answered Oct 16 '13 at 23:40
Amy Blankenship
7,13711836
I think that Kate has it right that you need to have a plan. However, I actually did a rewrite of an existing project, so you might find it useful to hear how I did it.
The first thing I did was write down all the tasks I could think of that needed to be done before we had a bare-bones usable version. I then wrote down estimates of how much time each would take and put them in a spreadsheet. Ultimately I also entered them in Asana so that anyone on the team could see where I was in the project, but I always referred back to the spreadsheet for time estimates, because obviously it's easier to total numbers in Excel.
Once I had the spreadsheet, I was able to send out progress reports and provide estimates on when various parts of the project would be finished. I worked like a dog to make sure I hit my estimates (not necessarily to the hour, but certainly if I said I would have x and y done in 8 workdays I would make sure I hit that even if I had to work 10-12 hour days). This gave me more internal motivation than I got from my boss, since at first there was no deadline and we were still able to use the old platform.
And I still have the spreadsheets, which I could use to update my resume--but a year after the fact, the benefits of the platform are more interesting than the list of things I did to get there.
One thing you'll probably find in the course of writing all this down is that you don't actually have a clear idea of everything that needs to be done. Probably a big reason why no one wants to work on this is that their gut is telling them that they don't quite know what to do. Be the guy who can actually solve this by surfacing these issues and figuring out the requirements.
One of the tasks that clearly should be on your list of things to accomplish (but clearly isn't) is to get the project into version control. There's no reason you can't check in each piece as you revise it--to a branch, if nothing else.
BTW, it's possible you've put yourself on the "fire when practical" list by acting like a prima donna. I don't think I've ever had a boss who would even think to look at checkins to see who to fire--much as sometime I have privately felt that would be a good idea ;).
answered Oct 16 '13 at 23:40
Amy Blankenship
7,13711836
answered Oct 16 '13 at 23:40
Amy Blankenship
7,13711836
answered Oct 16 '13 at 23:40
Amy Blankenship
7,13711836
answered Oct 16 '13 at 23:40
Amy Blankenship
7,13711836
7,13711836
thanks but your approach does not really apply to my situation
– amphibient
Oct 17 '13 at 0:42
1
In what way? You can't break your task into smaller units of work and tackle those? That's what refactoring is.
– Amy Blankenship
Oct 18 '13 at 0:02
add a comment |Â
thanks but your approach does not really apply to my situation
– amphibient
Oct 17 '13 at 0:42
1
In what way? You can't break your task into smaller units of work and tackle those? That's what refactoring is.
– Amy Blankenship
Oct 18 '13 at 0:02
thanks but your approach does not really apply to my situation
– amphibient
Oct 17 '13 at 0:42
thanks but your approach does not really apply to my situation
– amphibient
Oct 17 '13 at 0:42
1
1
In what way? You can't break your task into smaller units of work and tackle those? That's what refactoring is.
– Amy Blankenship
Oct 18 '13 at 0:02
In what way? You can't break your task into smaller units of work and tackle those? That's what refactoring is.
– Amy Blankenship
Oct 18 '13 at 0:02
add a comment |Â
I think they do. This issue predates my start date with the company. I think it should have been attended before I even started. I think other team members didn't want to work on it because they knew how thankless and open ended it would be to work on it, and unredeemable for quantifiable accomplishment credits. Because why else would it still be outstanding? I think someone more senior than me should be doing this architectural refactoring.
– amphibient
Oct 16 '13 at 21:20
1
If you're checking in revisions to vcs on a major project how is that not quantifiable? Just push/merge (if you're using git, replace with your vcs terminology otherwise) a couple times a day, then you'll have measured progress. Closing minor tickets that take <2 days to solve is not generally a responsibility of leads/seniors. Take it as a challenge and embrace the development of your skillset!
– Andrew Bartel
Oct 17 '13 at 1:14
i am saying that i am not checking such changes in because the project is analysis-heavy up front...
– amphibient
Oct 17 '13 at 1:18
1
Easily measured work assignment != Senior engineer work. That is for juniors and less experienced positions. How do I get paid at a senior engineer rate while only having junior engineer expectations would be a more accurate title for this question.
– IDrinkandIKnowThings
Nov 14 '13 at 1:32