0

I just got laid off of a job after just 5 weeks. I have worked, and was hired as Senior Engineer working middle-ware/server-side with a bit of client-side scripting work here and there(jquery comes handy in these cases),and then given a "training exercise" to, as I assumed, help me ramp up on a client-side framework working with native JavaScript, that was new to me.

So, thinking like a "Senior" programmer, I jumped into working to gain the deep understanding of client-side framework, and the various ways it worked to process my calls, so I can better tackle the task and others to follow.

After about 3 weeks of working on it(company orientation meetings and all), I was about 96% through but the client decided I have spent too much time in working on it. The expectation was that I would spend at most a week on the project and ramping up - copy-pasting where I could - to get the task over with.

I understand now that though I was brought on-board as a Senior engineer, I was in fact expected to first learn to work with the new library(copy-paste wherever I could), and then gain the understanding required over time, while working and pushing out code that is production ready, written in that library.

There was daily communication of updates during SCRUM meetings every morning.

The question here is .

QUESTIONS

1) When you find yourself expected to learn new technology in a very short time, and you have not only informed your manager of your inability to complete the training in such a short period, but made sure to provide daily updates, and ensured the line of communication stayed open for anyone who had additional questions, what do you do?

2) In the scenario above, was the client's expectation (complete training exercise within a week, start churning out production-ready code by the next week) unrealistic or was it in line with an "Agile" approach to learning that I am likely unaware of or not trained in?

OR

2) Was my approach, which I assumed to be in the best interest of the company, to spend at least a month ensuring I gained solid grasp of this new technology so I could produce higher quality results than those before me, wrong?

3) Given that this supposedly "agile" training approach is unfit for me, how do avoid being locked into such a commitment on future assignments? How do I stress that I require a good amount of time to learn new technologies without hurting my chances of getting the job during interviews?

SCRUM <=== A.K.A Daily Update Communication Meetings

A stand-up meeting (or simply "stand-up") is a daily team-meeting held to provide a status update to the team members. The "semi-real-time" status allows participants to know about potential challenges as well as to coordinate efforts to resolve difficult and/or time-consuming issues. It has particular value in Agile software development processes,1 such as Scrum, but can be utilized in any development methodology. The term "stand-up" derives from the practice of having the attendees stand at the meeting, as the discomfort of standing for long periods helps to keep the meetings short.

The meetings are usually time-boxed to 5–15 minutes and are held standing up to remind people to keep the meeting short and to-the-point.[3] The stand-up meeting is sometimes also referred to as the "stand-up", "morning roll-call" or "daily scrum".

There are three questions to ask and answer in the daily stand-up.[4] Though it may not be practical to limit all discussion to these three questions, the goal is to stick as closely as possible to these questions:

What did I accomplish yesterday? What will I do today? What obstacles are impeding my progress?

To help cement the above, please visit the SCRUM GUIDE . . . the guiding

principles of SCRUM by those who came up with the idea.

PS: For those who are not thinking this one through. As explained earlier, I was close to wrapping up my training. I was in the middle of customizing the solution for the training exercise to show that not only had I learned the inner workings of the framework, I could also customize, troubleshoot, and re-create existing controls in this new tool. And Yes, the client did pay for me to acquire all this knowledge which I have now.

closed as unclear what you're asking by Jim G., Michael Grubey, jmac May 12 '14 at 7:48

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I think this depends on company culture. Some (most?) will expect you to be productive as soon as possible and not "waste" time learning. – user19432 May 11 '14 at 9:05
  • 1
    Could you clarify if the work in this position was indeed part of an Agile process, or if you are using the term "agile" to mean "nimble and quick". While the methodology and the term are related, there's much more to it than that, and knowing how you're using it here would definitely produce different answers (e.g. how to work within a company's methodological process vs how to be more efficient in my own work). – jcmeloni May 11 '14 at 12:35
  • 2
    What did you and your manager discuss about your plan for ramping up when you began there? Or didn't you? – Monica Cellio May 12 '14 at 2:17
  • 5
    As it currently stands, this sounds more like a complaint about what happened than a question about the workplace. It would be better if this were cast as "how do I prevent this sort of problem in the future?", which is an answerable question. Right not it feels more like "this bad thing happened; am I right?". That may not be what you intended, but that's how it's sounding to me. (Also, if there is important information in the comments you should incorporate it into the question; comments are temporary post-it notes to improve a post, not an extended conversation.) – Monica Cellio May 12 '14 at 3:16
  • 1
    Hey user, I've put your question on hold for now. As @Monica pointed out above, this sounds more like a complaint, and it isn't clear what the "practical answerable question based on a problem you're facing" is as explained in our help center. If you could edit your question to clearly state what the problem was, and what sort of a solution you're looking for, it will be automatically reviewed by the community for reopening. Thanks in advance! – jmac May 12 '14 at 7:50
7

Was I being unrealistic with my goal as a Senior-level programmer to first gain deep knowledge, before jumping in to build production-ready code?

Yes, because you didn't communicate with your superiors about what was the timeline and what expectations did they have. Do you usually get a few weeks to work alone and just do what you want in your past positions? While I have had grace periods in various jobs, this is usually more than a little bit of a red flag and I have had some positions where I was terminated after a few months because of not performing to expectations.

I guess I am trying to understand if this is some new trend that I need to expect, and ways of adopting this "Agile" approach I guess?

No, this is about communication of expectations. They thought you'd take a week to learn this new stuff and have something to show after a few weeks while you thought you could just study for that whole time. Do you not see this as a basic communication issue?


I'd likely suggest having weekly 1 on 1 meetings with the superiors rather than a team wide meeting to determine expectations. This is different than a daily Scrum where each side risks embarrassment as if it seems like someone isn't clear about what is happening this doesn't get picked up.


The daily SCRUM meetings are for covering what was done yesterday, what will be done today and what blockers one has. This doesn't cover the question of what is expected of you as an individual contributor. The company may use a pseudo-Agile methodology here that is what you aren't getting. While there are daily meetings that cover some basics, could your manager really review your progress in front of the team in a way that wouldn't seem demoralizing? While you may not think this could be embarrassing, I'd think that management's expectations of each person's contributions is something to be kept private on some level. I wouldn't expect school teachers to pull up each student and read their report card out loud in front of the class which is pretty much what I'm referring to here. At the same time, do you think it is fair for the rest of the team to be present to hear about what management's expectations were for you without causing other possible issues as the rest of the team may want this and if each person is taking 15 minutes, this could be quite the time sink for the company.

  • 4
    I'd say this is a communication failure on both parties. The employer/manager should have set clear expectations of delivery schedules, and OP should have been making regular specific updates of progress against timelines. In all of my jobs the first few weeks have involved very heavy communication regarding expectations and progress towards them (re: daily). – Joel Etherton May 11 '14 at 13:13
  • Actually, I did give DAILY ( I mentioned "Agile" as sort of way to let you know to think of the daily updates etc.) updates during scrum meetings of what I would be working on for the day. I did that and even explained the reason why I believe it best for me to not simply do cut-paste work so I can get pushed into working on code to be moved quickly into the production environment. – user272671 May 11 '14 at 14:00
  • ****comments removed****: Please avoid using comments for extended discussion. Instead, please use The Workplace Chat. On Workplace SE, comments are intended to help improve a post. Please see What "comments" are not... for more details. – jmort253 May 13 '14 at 3:55
4

The client never laid out its expectation on how you were supposed to go about learning the material until it let you go. So I wouldn't blame you for failing to read the client's mind. I find it a bit rich that the client would expect you to push code that includes APIs from a framework that you don't know in less than a week.

It takes 12 to 15 months of full-time study for someone to become a good to very good Javascript software engineer - I know it because that's what is taking me: 12 to 15 months of my life. Javascript is deceptively easy to get started with but the happy learning experience ends within a couple of weeks: you can be happy, or you can learn. Just not both.

Learning Javascript is a chicken and egg question. You don't really learn Javascript unless you learn the frameworks, and you don't work with the frameworks effectively until you understand Javascript. You can do some cosmetic changes by cutting and pasting code but I'd be leery of letting anyone push code that they don't quite understand into production. The scenario of the code breaking while in production with no one having a clue as to why and how the code broke is a worst-case scenario that I don't care to live through. Unless the framework is trivial to learn i.e. less then ten well-explained, well documented and well-exampled APIs, the client is playing Russian roulette with its production code.

Personally, I think that the client is being unrealistic and the result of the client's approach would be to introduce booby traps into its production code. With the booby traps being triggered at the worst possible times.

I think your approach is the most realistic and safest way to get it done i.e. push code using APIs from a framework that you never heard of into production.

If any failure of communication occurred on your part, it is your failure to educate the client as to the right way to get it done and to set the client's expectations accordingly, ahead of time. The client might not be happy that it is not being told what it wants to hear, it might have passed you up but you would have been spared a dismissal :)

If it's any consolation to you, I believe that every successful professional should have been fired at least once :)

You said you want to practice Agile? If I understand what I am doing, I do everything ten times faster and with more confidence, I troubleshoot effectively and quickly and I maintain production code so that it doesn't break. Agile presupposes that you know what you are doing, and why. Can't do Agile with just cut-and-paste :) Not understanding and running around like a headless chicken is not Agile :)

Follow-up comment from @user272671 "Thank you. I agree with much of what you have there. I guess my question is, going forward, should I interview for a job in an established "Agile" team, should I also ensure to demand I be given adequate time to ramp up on any new technologies I will need to work with, and maybe ensure this is put in writing before I even consider any offers from such a company? Is the best way to get around this happening again?"

As my favorite actor Clint Eastwood used to say: "a man's got to know his limitations"

What I'd do is be pretty straightforward at the interview, let them know what I know and what I don't know and what it takes to get up to speed with their technologies. Estimates are rough and of course subject to revision as I get deeper into it - The point is to constantly keep open the lines of communication with the client and to manage expectations. Going into radio silence will get you killed :)

In the specific case of Javascript frameworks. I'd demand right at the interview a chance to preview them, look at the documentation and if possible to practice with them before my start date. I'd tell them that it takes two to three weeks to be familiar with the frameworks - familiar enough to write code that will not break down on me without me having a fair idea what happened and what to do about it. I have gone past the stage of learning Javascript for a couple of months now. Right now, my focus is understanding Javascript. The payoff is being able to do stuff in a matter of seconds or minutes that which used to take me hours or days to do, and to see what's wrong with someone's code just by glancing at it. That understanding also usually - not always - translates into a far shorter learning curve if I have to ramp up on some brand new framework, hopefully because I've seen elements of it in other frameworks.

I want to get to the point where I know enough and understand enough to be able to react on reflex, without intellectualizing anything :)

Not the answer you're looking for? Browse other questions tagged or ask your own question.