Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Sometimes I have seen some code or part of the project which I could improve but is not related with my current team project.
Those times I have a conflict because despite wanting to help, many teams lack enough people and doing extra work seems like betrayal. Obviously any managers will appreciate much more if you focus your effort on their tasks
What do you do in in these cases?
I have two guiding principles in cases like this:
I am here to do what my boss wants. If it's sweep the floors I can either do it or find another job but as long as I'm here that's what I'm to do.
If the boss makes a bad decision and I know better and tell him and he decides it anyway, it's the boss's prerogative. If I don't tell him then it's my fault.
Unless there's overriding circumstances this dictates that in the case where the code is outside my assignment I tell my boss that the code can be made better, and give him an idea what that means to him in real world terms, and ask whether he wants me to do it or not.
Yes, it does come back to bite me sometimes when I don't just do it, but he's paying me to do X and if I'm tinkering with Y then I'm not doing what I'm paid to do. He just has to pay me to fix it when it does come back to bite me(us)!
I think the key part of your statement is this:
which I could improve but is not related with my current team project
This sounds harsh, but it is based on experience and should be read with an open mind - keep out of it. One thing you learn as you get more dev experience under your belt is that you stay in scope, don't go diving off to fix something that is not scheduled. Here are a couple of reasons why:
when someone is planning the project, they are working with a known set of problems. If you randomly decide to "fix" things you are changing that known set, it is like when you are navigating using a map and someone is changing the map on you
you may think your fix is good for the product but it introduces extra complexities, like who is going to test your fix?
no matter how good you think you are, you run the risk of introducing another bug or unintended side effects into the application
how do you communicate your change to the other team members who may be working in that area?
how do you know for sure the scope of your change, how do you know that you haven't suddenly changed the context of a piece of code elsewhere?
You have good intentions, but if you start doing things like this you may be seen as a cowboy, and others will dislike you pretty quickly.
It is a skill you have to learn - know when not to touch things. You will see ugly code - don't touch! Don't recode things simply because you think it can be done better.
I hope this helps :)
I worked for a small company in the past, and if I saw something that I knew would impact me or someone else down the road, I generally fixed it then and there if I could do so in a short time frame without breaking anything.
You know the kinds of problems I'm talking about. If I don't spend 10 minutes to fix it now, it's going to cost me 30 minutes (over and over) later.
Otherwise, it went on the whiteboard with the other things to do (which was always full) and someone got around to it eventually.
You either clean it up when you're in someone else's house, or you step around their mess. Both choices can cause trouble. Which to choose depends entirely on you and your situation.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have a project which requires some complicated components built. Some of these components are promised by some obscure software packages which are proving to be poorly documented and difficult to configure and use.
I am wondering where other people draw the line during their software research phase in deciding whether to build their own packages or sticking with trying the existing packages?
And what percentage of the total project time should I spend on this kind of research?
Thanks in advance,
Alex
Ask yourself which is likely to take longer, hammering the components to fit your needs or writing your own.
Personally I pretty much always use solid, comprehensive libraries (jQuery for web development, DevExpress for WinForms) and fill in the gaps with my own code.
The only exception I remember off the top of my head was a tooltip plugin for a web application. I tried like 3, wasting hours and hours adapting each of them to my needs, even modifying their source code, playing with their images, fixing obscure css tags that baffle ie7 (cause ie8 defaults in ie7 mode on the intranet), but never quite getting it right, then just gave up and rolled my own in half an hour.
Not to say there aren't plenty of good components out there that are flexible enough to be used in active development environments, but you're unlikely to find them in the heat of developing your stuff with deadlines looming overhead. Use your free-ish time to look for them and bookmark them, try them out in a few toy projects and see how they work, so the next time you need something like them you know what to use.
If you have to fix some minor bugs or otherwise have to observe some patterns the code doesn't currently take into account, consider contributing back into the code base as a good citizen.
If you find yourself having to substantially recode some pre-provided code to get it to work, then maybe the fact it was already "coded" is irrelevant. Bite down and chew.
If it's bologna and you need to reinvent the "wheel", consider that you've got a job that may not be compensating it's actual value.
I usually draw the line at about 1/10. Meaning if it has already taken me, say, 1 day and I still haven't gotten the off-the-shelf thing working and it would only take me 10 days to do it myself, I do it myself.
Even when it takes a little longer, it's often better in the long run to avoid the complicated, hard-to-use thing. Or, at the very least, I get a better idea of what I really need and I can pick an off-the-shelf package with my eyes wider open.
Well i think it all depends.
Given that, it is possible for you to spend more time than u would have used for development at trying to configure and understand. I would say if you are good enough to create faster than learn the improperly documented on then go for it.
Else if the existing promises great features and will not take too much of the entire project time then go for it. Often it is very difficult to draw then line. It all depends on the situation at hand.
Also you could look for alternatives to what u have now.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
If you are the lead programmer at a company and you need to complete a project that would require skills/knowledge that no one at the company currently has, what do you do?
I am not talking about something simple you can ask for help on stack-overflow for but for complex problems that you do not feel comfortable tackling and would take a significant amount of learning to be ready.
So at the point whats the best step to take?
Be honest with your management team, make sure they know. Don't ever try to mislead people about the scope of your knowledge - it doesn't impress them and only causes you problems.
Work with your team to evaluate your options - it may be possible to change technologies, or perhaps someone else in the organization can help mentor or support you. Changing course earlier on is easier and less expensive than later.
Adjust your project timeline to take into account the potential risk and delays caused by working beyond your core strengths. If you don't have enough knowledge to estimate the risk, be very conservative in the confidence factor of your estimates and timeline.
Look for an expert in the domain/technology and see if you can engage them either as a consultant or advisor on your project. Nothing makes a bigger difference than prior experience in a domain.
Take some time to try to create a simpe prototype or proof-of-concept in the domain/technology you will be working on. Look for possible issues that could emerge. Sometimes unexpected problems surface when you try to create a simple prototype - this can help steer the effort when working on the real thing.
See if the scope of your project can be scaled back. If you are already "behind the curve" the best way to improve your odds of success is tackling something smaller, rather than larger.
Seek out advise from people you trust. Especially people whose expertise and knowledge has some bearing on the problem or technology you're taking on. They may be able to give your more specific advise or ideas.
You have to take it outside the company to someone (person or consultancy) that can complete it. This means a contractor/consultant that will be with you for a temporary period of time. If possible have them work in house with your and your team and make part of their responsibility to train you.
You may have to explain to management that without this, the project could fail and will probably be late and over budget. Don't worry about outsourcing some projects - you and your team will still have lots of work.
Temporarily hire someone who has the expertise you're missing, and make sure they're prpared to transfer their knowledge to others in your team as well as work on the problem at hand. Be prepared to pay serious money; but if the problem really is complex, chances are you'd take much longer, get a much worse result, and pay more overall if you try to figure out out without any help.
First, +1 to Borgwardt, Oded, Bushkin. Great answers here. Now my two cents...
Your path forward should consider whether this is a skill/technology i.e. "capability" that your company needs to have internally. Depending on this, take the advice of either #Oded (Outsource) or #Michael Borgwardt (hire a contractor to do some knowledge transfer), or spend a lot of time (if you have it) and develop the capability on your own. For example, suppose you're going to interface with some purchased package that spits out magic numbers in some binary format. Hire a contractor to write the interface. Suppose your VP of fulfillment wants you to interface with a FedEx web service, and nobody at your company knows SOAP. And you know that more SOAP is coming, for all suppliers and partners. You'll need SOAP skills in-house, so get some training, do a prototype, and maybe bring in some outside help.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Do you ever run into a bug where you are just out of ideas and don't know what to try next, and you're getting really annoyed? Are there any general ideas on how to break out of this mode?
When I get blocked like that, the best advice I've found is leave for a while. Whether it's going for a long lunch or leave for the day. Come back fresh and take a new look. Most of the time the answer will be staring you in the face. So far a 10 minute coffee break hasn't been enough for me, but your mileage may vary.
Second, talk to your peers. Walk through everything you've tried. Just ask them to listen, and while you're talking it through, a lot of times, the answer will come to you.
Those are just the two that I use most often when I'm debugging blocked.
Five minute break
Utterly critical, lest you smash your keyboard.
Explain the problem in an email to your sister
Or your two year old son. Someone who wouldn't understand a word* unless you explained it very clearly. You don't need to send the email, you just need to be certain that you understand it inside out. You be surprised at how many times simply restating the problem suddenly makes it obvious to you where you went wrong. This is a good way of discovering what your assumptions were about the problem, and how they might not necessarily be correct.
*That link is to an excellent answer by JaredPar on a different SO question.
Talk to a colleague
By this point you've already 'emailed' the family pet, so you know that you've hopefully covered all the stupid aspects, it's time to talk to a real person. They may have experienced some obscure thing in the past that reminds them of this situation, and they'll definitly have a different perspective. Try to make sure you are clear about what the problem is, not what you think it is. You don't want to bias them. You can and should talk about what they've tried, and explain why you think the problem is in that area (you're probably right) but you don't want to close your mind to their suggestions, even if they don't seem right.
Look at the code again
By this time, you should hopefully be less violent, and you should be armed with new ideas. Start by re-verifying the bug. A simple step, but I've been frustrated for hours on a bug that was in our test script and not in our code. Once you've verified the bug again, start at the top. Verify EVERYTHING. Put a breakpoint at the last point you are 100% confident in, and then work your way forward until you find that the output is broken again. That's a huge success because you now have a hopefully smaller code block to investigate. Then, if necessary, pull in a colleague to look at the actual running code.
I usually take a break... if that doesn't work, I sleep on the problem. (Actually, to be honest, I should say that I spend a sleepless night mulling over the problem).
I almost always have a list of possible solutions ready by morning. :-)
I usually take a few steps:
look at the code that is involved in the functionality that has the bug and place logger messages in a way that they will help me narrow the problem (this allows you to look at the logger later on when you are not that annoyed anymore, and maybe find useful hints :P)
ask my senior collegues for hints
call the client to have a clear understanding of when the problem arises
I usually end up in that mood when I didn't take a structural approach from the beginning.
By iteratively narrowing the area where the problem can live and trying to write the smallest code base that can reproduce the error, I haven't failed yet.
Others have mentioned taking a break or "sleeping on it". This technique is known as (amongst other things) Incubation. Once you embrace the idea you can take it further too.
One important aspect as to really leave the problem behind, confident that you'll have answers later. The dangerous otherwise, especially if sleeping on it, is that you'll be worrying over it up to the last minute, then this becomes an endless cycle that your mind gets caught in overnight. You'll probably end up waking up not too well rested having dreamt many circular dreams. Do this too much and it's a path to depression.
I think if you run into that kind of problem it is time to do some serious refactoring...
Also it could indicate false assumptions. Try to assume programmatically all that you are 'just' assuming. See to it no method-invariants are broken of any methods that are in the stack.
Another good option is to bounce ideas off other developers/team members. Sometimes they will ask you questions you hadn't considered.
If you work alone, it's a good idea to have a few fellow developers who you can chat to to troubleshoot with some different approaches. You'd be amazed how often a fresh perspective can be the breakthrough you need.
Try David Ungars "Shower Methodology":
"If you know what to type, type. If you don't know what to type, take a shower and stay in the shower until you know what to type"
This kind of summons up what the majority likes to do. Take a break ! Doesn't matter what kind of break it is, as long as you are not thinking of the things you were doing before the break. Distraction in any form is good.
Cheers !
I usually take a dry run through the offending method/function, step by step. And don't assume the bug is coming from there, it could be coming from anywhere before it.
Use a proper debugger, don't use a series of printfs.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
My team (4 people) have just reached a major milestone in our development, putting us at about 2/3 finished, but I guess the stress has caught up to everyone and all the gears have ground to a near halt, progess is being made at 1/5 of the original speed. I wanted to ask the SO community how to best deal with this, I've identified the following problems.
Lack of clear focus and direction. We seem to be hitting small side improvements, but not working towards anything central to the project so I think that's causing a lack of enthusiasm.
Coming down off of a very strong development push. This seems to have made everyone want to really "relax" which is fine for a bit, but progress still needs to be made.
The remaining tasks are more tedious than glamorous. This is the nature of the beast but I have yet to tame it effectively.
Any help is appreciated.
Some downtime is necessary after reaching major milestones. People need to relax and decompress. Pushing on just carries the stress and fatigue forward and the team won't be working anywhere near their potential.
Give everyone a couple days to a week off and let them come back fully refreshed and ready to continue.
Tell them you only need 3 people to finish the project.
I think the key is when you say the remaining tasks are more tedious than glamorous. Yep life is like that but many developers don't want to work on tedious. None the less as the lead, it is your reponsibility to determine what tasks need to be done and assign them to people to do. Same as with the more interesting tasks, maybe even more important (someone will almost always step up to do the interesting stuff, not so much with the tedium).
So assign your tasks, give them their deadlines and follow-up on the progress they are making. If you have any of the more interesting tasks left, don't let anyone have one of those to do until he or she has completed his share of the tedium. In fact dangle the interesting tasks left as a reward for getting the tedium done faster or doing the most of it.
If you don't have any more interesting tasks left, thn maybe you can generate some competition to get the rest of the stuff done.
It's ok to be slack for a few days after a major push, but if it lasts more than a week, I think you need to get the team together and talk about what needs to done to fix the slacking.
Do something, other than work, as a team. Go to lunch, happy hour, laser tag, anything you can do as a group that is not work. A short break from stress can be a huge relief, and hopefully can reenergize your team for the final push.
I also strongly believe in "slackweek". If the deadline for the entire project isn't too close: just let everyone do what they want for a period of time. Could be write some tests here, align some stuff in the gui, read up on the latest in bla, whatever. Up to you if it has to be work on that specific project or just something useful overall.
THEN, you have a big "launch" meeting where you talk vision and goals for the remaining third - big picture stuff, and get everyone aligned again. I'm assuming the stuff left is really needed to give the customer a complete product so that it can be motivated for.
Good luck!
Add an easter egg! It doesn't improve the core project, but it helps give developers a sense of ownership.
Also, it can be helpful to set aside time for "pet peeve" cleanup. This gives developers a chance to fix nagging issues that are important to them. This helps improve the project, and at the same time allows the developer to make progress with something that is important to them. It helps keep the excitement level up.
Are there clear deadlines/milestones coming up soon? That would be something to consider as having a target date can help provide some focus.
The momentum being lost, does it tie back to people just being burned out, not as motivated as they were before or the work becoming much different, e.g. working out specifics on vague requirements rather than the cool parts that are done now?
One of the things Agile gets you is a finer focus on where you stand, what you've done, and what's left to do, within the next few weeks. There are concepts of "backlog" (what has to get done) and "velocity" (how fast are things getting done). Since each iteration is typically about a month, it's very clear to see when the team is not working at the projected/required rate, or working too hard. You might be able to borrow some concepts from Scrum for these purposes.
A more straightforward solution is to remind them that if they keep working at a reasonable pace, there's no end-of-milestone crunch time that makes everyone's life hell.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I find way too many projects to get involved in, way to many languages to play with (and way too many cool features within those languages), and way too many books to read...
How do you guys stay focused and actually get anything done, rather than leaving a trail of partially complete "experiments?"
Seems like there are two types of developers: Tinkerers and Entrepreneurs.
Tinkerers want to know how every little thing works. Once they get the hang of something, they're distracted by everything they don't know. The tech world is brutal for a Tinkerer because there's so much to learn and each new year creates more. Tinkerers are proud of their knowledge.
Entrepreneurs want to know enough to build something really great. They think in terms of features and end-user experiences. You never hear them argue about Python over .NET over Java over C because they just don't care. They're more interested in the result of a language versus the language itself. Entrepreneurs are proud of their user-base.
Sounds like you're struggling with your Tinkerer tendencies. I've got the same problem and have found only one thing that helps - find an Entrepreneur developer that you thoroughly respect. When you put the two together, it's unbeatable. The Tinkerer plumbs the depth of every technical nuance. They keep the Entrepreneur technically honest. In turn, the Entrepreneur creates focus and opportunity for the Tinkerer. When they catch you browsing the Scala site (assuming you're not a Scala developer), they reveal a new challenge in your existing project. Not only that, they're much better at understanding what non-Tinkerers want.
Money, and the feeling of accomplishment that goes along with actually finishing something. When I first thought about working for myself I started coming up with ideas of software that I would develop and then later sell. Of course, I really didn't know if what I was making would actually sell, so it was easy to get distracted and jump at new ideas.
So I decided to go with being a contractor/consultant. When you know that there is a buyer for what you're making, and that somebody is waiting on it, it gives you motivation. If it's an interesting or challenging project, there's a rush associated with finishing it. So that adds extra motivation because you want that rush more and more.
Once I got a fairly steady flow of work-for-hire projects, I found that I can stay focused on my side projects better because I have incentive to practice good time management. I give myself a certain amount of time every day or week to work on my side projects, and it helps me stay focused when I take that time.
Of course, I still go off on tangents occasionally and start new side projects as well, but the ones that I am most interested in I have been able to stick with.
Also, after you finish some projects, then you get a better feel for what it actually takes to go from conception to completion, and it makes it a lot easier to do it again and again.
I think a good programmer may well have lots of unfinished "experiments" hanging around, this is a good thing.
Usually with a good manager, you will be held accountable if your work is simply not getting done. If you're a student, though, it's tougher. I realized that it is impossible to learn everything you want to.
I limit myself to only learning 1 or 2 new languages per year, and only 1 book per month. That seems to be a nice balance between programming chaos and getting my job done well.
Kudos for having a great learning attitude :)
Probably the best motivator (for a team or an individual) is to set goals early and often.
One of the best methods I've observed in project management was the introduction of "feature themed weeks" - where the team (or an individual) was set goals or deliverables which aligned under a general flavour, e.g "Customer Features", "Reporting and Metrics" etc. This kept the team/person focused on one area of delivery/effort. It also made it easy to communicate to the customer where progress was being made.
Also.. Try to make your (or your team's) progress visible. If you can establish an automated build process (or some other mechanism) and "publish" incremental implementation of work over a short period of time you can often gain traction and early by-in which can drive results faster (and help aid in early course correction).
1) I leave a utterly MASIVE trail of unfinished stuff, all side projects of course.
2) When I need motivation to work I open my wallet... That usually does it for me.
I'm building an app I plan on selling and see it as a way of making extra money or reducing the amount of time I spend working for other people.
My wife likes this idea and her encouragement has managed to keep me focused longer than normal as it's now "work" rather than "play"
I find that getting involved with the "business" side of the equation helps tremendously. When you see how much benefit the actual users of your program can get out of your creative solutions to their problems - it's an extreme motivation to provide those solutions to them. :-)