Anyone got any experience of teams doing pair programming where there is a mixed IDE environment? I'm a long time IntelliJ user, others use Eclipse, which you may have heard of.
In my mind pair programming involves a lot of passing the keyboard between the programmers. But every time I get the keyboard I grind to a halt as I don't know to do anything anymore. (It's like suddenly I'm an idiot!)
Now I could, probably should, learn my way round Eclipse. (Not starting a holy war here about relative merits.) But I wonder if anyone else has got an opinion?
I don't see the need for passing the keyboard around. In my view, you work on part while the other half of your pair looks over your shoulder. Sometimes I imagine you would have to take the wheel, but generally not every 10 minutes. If he types for 4 hours, then you switch places, just switch IDEs at that time.
I agree you should learn the tools that are used, and if there is an actual published or documented standard you should follow it, but if you are allowed to use any IDE you want, then I don't see an issue. But if it inhibits your ability to deliver, then maybe you pair up with someone using the same IDE as you.
About 10 years too late for the OP, but this question is still highly ranked in search engines, so others interested in remote mixed environment pair programming can try CodeTogether. It's available for for IntelliJ, Eclipse, VS Code and IDEs based on them.
Participants join in a browser, but get a full IDE-like experience with IntelliSense, validation, reference searches, navigation, etc. CodeTogether is simple, fast, free, anonymous, and encrypted. The plugins/extensions are in the normal marketplaces/registries you'd expect and are also available on the website.
Full disclosure: I work for Genuitec, the makers of CodeTogether, and we really hope you enjoy it. Any constructive feedback on Gitter or GitHub is always appreciated.
I have not done this in a multi-IDE environment. But pairing is, to my mind, far and away the best way to learn IDE features. So you should come up to speed quickly on Eclipse, and your colleagues, likewise, should get a handle on IntelliJ in short order. Both of you will become better versed in both environments - and that's a good position from which to settle on a team IDE, should you choose to do so.
By comparison with other means of learning, pairing teaches you the features that are useful to you (or your pair, who probably has a similar set of needs). You learn almost by osmosis; as your pair uses a feature you may find yourself asking, "how did you do that?" or "what did you just do?" This is teaching you the features you need, exactly when you need them.
In your situation, there may be additional value: you may find yourself wanting a feature that your IDE offers; your pair may never have encountered it (but it might be in Eclipse, too). So you spend a minute tracking down that feature, and now both of you have learned new (and useful) functionality of the IDE.
Standardize your environment! As much as you need a common source style, I would argue you also need a common way of working, including having a common IDE. All kinds of settings, knowledge, plugins, etc. is much easier to share, including your example about pair programming.
In pair programming, the pair should standardize on an IDE.
My suggestion would be either to pair with another IntelliJ user or, if the rest of the group is on Eclipse, start learning Eclipse.
You're going to lose too much time switching between IDEs to gain the efficiencies of pair programming.
You could have both IDEs loaded on the pairing machine and switch between them as needed, but I'd recommend standardizing IDEs with your pairing partner. You might want to bring this question up in your next retrospective and see what the team consensus is.
Related
I have been using WingIDE for python program development for several years, and in general I am satisfied with it (esp. with their technical support). The learning curve for WingIDE was rather steep (at least for me). I am now considering some projects that I will require that I work with PyDev-Eclipse.
What kind of learning curve (steep -> easy, or not steep -> not easy) might one expect with PyDev?
I don't think there's a right answer here... Experiences vary a lot (I'd suggest following the Getting started tutorial http://pydev.org/manual_101_root.html and then judging for yourself... I think the basics should be easy to grasp, but as with anything else, to really master it will take more time, especially getting used to shortcuts and discovering what it's capable of).
I agree with Fabio that there is no simple answer. For Wing, start with the Tutorial in the Help menu. That takes you through the basics you need to know to work with Wing and use the debugger, and you can learn the other tools and capabilities more slowly over time.
The choice of IDE is as personal as choosing a keyboard. But for both the experiences of others sometimes help to make a choice.
In my case Wing has made the difference between advancing my Python skills relatively quickly, and some months of being bogged down by not understanding basic concepts. I have really found that the functionality Wing offers to go through existing code helps to understand Python and existing code more quickly.
With Pydev I got bogged down in the complexities of Eclipse. With Wing I felt that I was standing on the shoulders of people who grokked Python deeply. Note the word "felt", it is a very subjective thing, and you should most definitely take some time to try out what works for you.
Some things about Wing that make me believe it has helped me learn Python much more quickly than I would have otherwise: The Auto-Enter Invocation Args setting which shows up the PEP-8 way of invoking arguments to standard functions you are calling. And the go-to-definition and find-points-of-use functions that I have used many times to try to figure out how existing code works. This may all be available elsewhere, but it just works immediately and in a very coherent way in Wing.
Now i know that this one is actually not a very technical question but one that has been bothering me for some time. Actually we are using a lot of C++ and PHP at our company and some of our developers are really hoping for a new and modern language to come by to help us getting more productive. I have been talking about what scala can do and the other coders seem to gain some interest in the language. The tough job is, how do you convince your boss to consider scala as a language for the company. I saw the presentation "Sneaking Scala into your company", but it deals with the situation that you are using Java at your company which we don't.
How do you fight of the usual "that is just esoteric stuff" and "we can already do that in $LANGUAGE" arguments. I was planing to give a talk about Scala, and since I don't have much time I need ideas how to get people interested in the language rather then setting of reactions like "currying? we can already do something like this with boost::bind".
How did you guys do it?
Regards,
raichoo
EDIT: Gave my talk yesterday, people were very excited. My company is going to give it a try! Thanks for all your suggestions.
If you don't already have killer arguments, what are you basing your reasoning on that Scala will make your company more productive?
Don't like something then hunt for reasons to use it at work. Let the reasons speak for themselves..
"A hammer looking for nails"
Using it to do some stuff around the side, as datamigrations, testing and similar things will make sure the necessary experience is built and can give it some exposure.
ScalaTest is really nice to help with acceptance/integration testing. (Yes, I know it is nice for unit testing, but I do not see that immediately happening with C++/PHP target code, and it would probably be unwise).
Proof of Concept and other Prototypes are great for 2 reasons
1) It showcases the capabilities
2) You are certain they will be thrown away if you have to reimplement them in C++/PHP
Now a bad time to introduce Scala would be when you REALLY need it : hopes will be high, it will not immediately work as intended, hopes are dashed and everybody will blame Scala. As a result it will be burnt for a long time in the organisation.
Sooner or later some suit will think it was his idea to introduce Scala and use it on a formal project. If that project is moderately successful, then it is sold.
These kind of changes are complicated people issues, and the harder you push, the harder you will face push-back. On the other hand the persistent mind can move mountains.
Redo some of your work related code in Scala and compare KLOC, code structure and performence, if it looks and works better, show it to your peers and your managers.
In other words:
Talk is cheap. Show me the code.
-- Torvalds, Linus (2000-08-25)
In case of our company (and I assume, many companies share the same scenario), move to Scala (from Java) was initiated by tech people, who 1. wanted to work more productive writing code (living in the 21st century utilize modern approaches), 2. have less troubles building concurrent applications (Actors concept promoted by Scala is a way simpler than Java thread-based concurrency) 2.1 have a simpler way of building scalable staged event driven architectures.
In our company, transition to Scala was more or less simple, because Scala was literlly sold to business people as a library to Java :) -> from their POV, we're still using the same platform (JVM), application servers, etc., but developers are having more fun from their work, and therefore, are more inspired and work more efficiently.
Maybe you could pitch Scala by showing off the suite of tools that is used for development? For example, if you are not already using Eclipse in your company, show your execs a demo of what a modern IDE can do for your productivity.
There is a book called "Fearless Change" (Linda Rising) that describes a pattern language for "powerless leaders" (I LOVE that role title!). SE-radio had a really motivating interview with the author: http://www.se-radio.net/podcast/2009-06/episode-139-fearless-change-linda-rising. Listen up on that interview to collect a few non-technical strategies that can help you in this struggle!
I haven't used Scala yet for any real business code, but I know people who have.
One group used it to write a tool to analyze log files. So they didn't use it for mission-critical business code, but for a non-critical tool to support the project.
Another person I know is an architect and he just went and wrote some Scala code on his own for some production code without telling his manager. After the code was deployed successfully he did tell it. One of the things he mentioned is that because Scala runs on the JVM, the people who support the application don't even notice - to them, Scala is just another library that's included with the application (they were already used to the JVM). Ofcourse this approach is risky and not everybody will be in the position or be willing to do this.
You could start small - use it as your personal preferred scripting language for small things that you need yourself. Tell your fellow developers about it and make them enthusiasts too. If they also start using it then you can step it up to make some side code for your project (such as for example that log analyser tool).
This isn't a really easy task. I would concentrate on the fact that you will be able to produce code and therefore products faster and with a higher quality. That's always the two reasons, business wants to hear from you and will listen to.
Maybe you can show an example of 1-2 very small projects you did in your company with C++/PHP and compare the effort, quality etc. with a similar/the same implemenation in Scala? This would be very impressive and should also convince people who are not on the coding side.
There was a very good talk at Scala Days 2010 by David Copeland:
Sneaking Scala into your organisation
The executive summary: Testing. You can use Scala for testing without affecting release code.
We are a team working on legacy code which is pretty old and written in languages of initial programming days. As the team members are trained in latest technology and are now put to work on legacy code, they are not happy. How to motivate them to work in legacy code also?
Send your team to meet users and watch them use software. They should find out what are most critical problems users have with that software.
Getting to know users makes work more real - your team will know that adding new functionality or eliminating some bugs will help some real person. That should motivate programmers to get boring job done.
Only cash can not make the developers happy. You should provide them good environment so that they can pay attention to their work.
Another thing is no technology is bad OR legacy OR older. Thing is if your company needs to maintain it, then you must keep it going. But keep all standards for designing, coding, testing, code review, interactive sessions etc..
Also you can motivate them to convert your legacy code to some new platform for better performance and maintainability. Every company does that even once i think, because they want to compete with other market products.
Also provide them some cool sessions for other technologies which are used in your company but they don't know or use. Let them be deeply in the things, give them proper time and support for problem solving. Main goal is to deliver on time with less rework and bugs.
Provide some rewards towards their work and keep them happy about their work.
thanks.
i really like "Send your team to meet users and watch them using software"
If i have to motivate my team, I will really ask my developer to visit the use and find out how much user is happy with the product.
I will really like to take challenge on how we can make it more better then what exist.
Do you have some scope for retiring the legacy code in the foreseeable future? If so, "we only need to keep this going until..." might sweeten the pill.
Are the team members experienced in the languages/environments which the legacy code is written in? If not, it might be simple reluctance to do something that they don't know how to operate. Possibly scheduling in some time for them to gain at least a passing familiarity might be in order; provided it's not too much of a paradigm shift from latest technology, it shouldn't be all that hard?
Are the team members only allowed to work on the legacy code team or can their time be split between different projects? I don't think anyone is going to be happy about spending a 40 hour week on FORTRAN debugging. But if you have to spend a few hours on the legacy code knowing that you can take breaks during the day to work on something you actually enjoy it's a little less painful.
And I'll reiterate what was said before about making sure the team members have time to learn and gain experience with the old technologies before throwing them in there. Try to make the training enjoyable too. Our legacy code training was set up as a competition to see who could come up with the fastest/shortest/most complete/etc solution to interesting problems rather than having to look exclusively at the code we were to be working on. Really, that could be applied to the team's plan even if you don't have time set aside for training. Add a little competition to the task at hand or allow a little bit of time for challenging and competitive side projects.
How are they getting rewarded for working on these legacy products? Do you know what motivates them? Some people may prefer timely recognition and praise while others may expect cash or understanding that this isn't necessarily what they signed up for when they initially took the job. I'd be tempted to suggest having 1:1 meetings to see what would they like that would make them happier. Is it more money? More flexibility in time off? Training in the legacy technologies? Affirmation that they are doing good work on these ancient systems, as the initial programming days makes me think of mainframes and other really old tools that one may wonder, "How much longer will this run really?"
Cash isn't the answer. Free food, soft drinks, whatever, that only goes so far at alleviating the drudgery of legacy code work. What about trying to change their perspective?
"Anyone can do good work with modern code that has a nice IDE with refactoring built in, a ton of resources just one Google search away, but we proud few, we band of brothers, we are good enough to do this with ancient procedural languages. We'll tame this awful mess of code and do it with one hand behind our backs and create processes and tools to make sure the next poor bastards won't have it so bad."
I would say the simplest way to attract the most positive emotion from developers to legacy coding would be to make the old new in some way.
Have a session or two to identify what it is that the legacy code does, and then get an idea of what it would take to do it anew on a new architecture. The "new architecture" part is key, because 9/10 times, it's the architecture that is dreaded (spaghetti code, pre-standard conventions, etc...).
If you can't get your re-write estimates approved, then at least work out a plan to get your refactoring of legacy code into the daily maintenance. At the very least your developers will feel as though they are working towards something, and something new at that, instead of just monkey-wrenching the old decay that no one wants to even remember.
Just my 2ยข.
You can for example try to do fancy things on the testing side. Try out mocking frameworks etc.
Try also emphasize that handling legacy code is a good experience if you want to become a solid programmer, since every technology becomes eventually legacy.
Extra cash? :) Don't know anything else...
Even if it's new technologies legacy code it's not always a pleasure to work on such code, so on "initial technologies"... i guess the only motivating thing is to discover how programming was these days...
The amount of Time required in spending motivating the team and learning the legacy code and fixing it half heartedly can easily be used to build the same stuff in new platform , given the amount of resources , IDEs , expertise , frameworks etc available for free, the Good news you have the system in place you just need to meet the same behavior in new platform unlike we have to build something new for some product whose behavior and user experience we dont know .
I'm a largely self-taught front-end developer only just making the transition into back-end development in order to be able to say yes to more projects.
I've found eclipse to be my favourite text editor for javascript and php, but I'm conscious that it (and other IDEs) have a whole load of features which I don't know how to use, or why I should want to use them.
I'd really appreciate some pointers on why using such-and-such a feature of an IDE helps you work more efficiently, write better code etc..., and maybe some links to useful sources of information.
Cheers
edit - I'm already converted to using ftp features and code explorer/function lists
You may find eclipse tips such as these interesting. But if your objective is to "write better code" then I think you need to look elsewhere. Understand the language you are using better, understand design patterns and the reasons whey people apply them, study testing techniques. There's so much else to spend your time on. Truly working smarter is the objective.
I would always advise learning what goes on behind the IDE and then using the IDE.
Get familiar with:
Build/Distribution processes (Like Make and others)
How compilation works, what are the component processes
How the IDE is generating things like autocomplete (scanning headers/source)
version control, get familiar with it on the command-line. It will mean you can deal with issues/requirements not filled by the IDE.
Once you know what goes on behind the scenes for the language/environment you are programming in ... the IDE is a bit mundane, just a modular text-editor on steroids.
Good luck
Maybe this is obvious, but in my opinion class/function/variable name refactoring is among the most essential features of any IDE. Constant refactoring is one of the secrets of making good code.
That's a bit of a difficult question to answer since most modern IDEs offer such a wide range of features. From a general standpoint, I'd become familiar with hot key combinations for repetitive tasks (saving, building, code folding, etc.) and how to install/enable/disable add-ons and plug-ins. That will make you more efficient.
As Aiden mentions, knowing how to to a build from the command line/compilation in general will be useful as well as version control systems. Get familiar with GIT and Subversion.
The IDE will not make you write better code. For that, you're going to need practice and some time spent reading/listening to podcasts. Read Robert Martin's "Clean Code" for starters.
Additionally, spend the time to learn proper TDD and the toolset(s) available for your IDE.
Developer tools and software typically do not provide solution suggestions in error messages. This makes sense for compilers because they are supposed to tell precisely what went wrong.
There are "lint" tools to provide suggestions, but AFAIK, few developers use lint tools regularly or even at all.
There is a large set of developer-oriented software that would do well to have a "suggested solution(s)" part to error messages. This is one of the great features that IDEs like Eclipse have. But software like web application frameworks, standard/popular libraries, etc. do not have this helpful feature.
Is this something that is just lacking in user-friendly design (one can consider this unnecessary, given that Google is so good) or is there a good reason for it? Do any compilers, frameworks, platforms that you use provide error messages with solution suggestions, if none, why not?
What do you want to see?
Error: Null Pointer Exception (suggested solution: Set the object to something).
I mean, it's not the error writers job to educate you. I prefer simple error messages that point to the exact problem, so I myself can determine just what is causing it this time. For me, this certainly lines in the domain of 3rd party tools; perhaps the compilers could provide extensive context to them, to do their analysis, but it's not something I would really find valuable.
The primary thing I want from a compiler or runtime error is context - where did it happen and where was it called from when it failed.
I think most modern compilers and runtimes (Java, Ruby, Go) do a decent job there, with line numbers and stack traces you can find most bugs. Even the Javascript options getting good, it certainly beats the good old "alert()" approach to debugging.
Isn't it fair enough to leave suggested solutions to the IDEs?
But I do agree that I have seen frameworks/libraries that were very sparse with error messages, and "NullPointerException at line 264" deep inside some third-party library where you do not have the source code tells you very close to nothing.
If this is an issue, I think it is primarily restricted to third-party libraries. The "good reason" is presumably that it was developed in a hurry in somebody's spare time, and they did not put meaningful error messages very high on the priority list.
It's hard for the solution to an error being presented. There are so many possibilities and as #silky pointed out, some just cannot be diagnosed.
Warnings are a different beast. In many situations modern compilers use these to say "I think you meant X when you said Y; you might want to check that."
A programming language has the opportunity to be the ultimate in flexibility in terms of user interface. You can make the computer do anything you want. The flip side of the coin is that if you type so much as one character wrong, it might have no idea along which axis your mistake was made, or where.
Systems with less flexibility offer more opportunities for offering solutions to problems. If you type (a b c) to your Lisp compiler and it doesn't know what a is, it's so close to so many valid lines of code that it can't exactly suggest a single fix. If you misspell "IDENTIFICATION DIVISION" at the start of your COBOL program, it's relatively easy for the compiler to spot the error and help you out. Most other languages lie between these extremes.
Programmers tend to move, over their careers, from less powerful and more structured languages, into more powerful and flexible languages. (At least, that's what I saw happen before Javascript became such a hot newbie language.) This means their discipline improves to the point where they are able to use tools that offer power at the expense of being told what to do. The environments I've used that can tell me what to fix, tend to be those that I dislike using.
It's no different from any other art. Look at musicians or painters or martial artists or actors or writers or chefs or even people learning to speak Spanish: when they're young and inexperienced, they're put in a system where there's a lot of structure, and if they make a mistake somebody can easily correct them. As they become more skilled, they need and want less and less support. When they've become experts themselves, they need no support at all, but the flip side of the coin is that you can't as easily point out what's right or wrong. If your kid colors outside the lines, you can explain the issue, but if Picasso or Pollock makes a bad brushstroke, what would you say? Or if Philip Glass puts a note out of place, or Bruce Lee turns his body too far into a punch? And who would want to work in an art form that's so limited that profane things aren't possible? COBOL compilers still exist if anybody really wants them, but far more people pay money for awful paintings than masterful color-by-number prints.
More directly, there's a site, ErrorHelp (nee bug.gd), that lets you type in an error message and get a result, and it's older than SO but nobody uses it. I've tried. Unless you're in a context where there's only one possible answer, a simple problem-encountered to suggested-solution dictionary does not work, and therefore it's an utter failure in any creative field.
Most IDE's have their own compilers. This allows them to do partial compilation, code refactorings, and many other tricks. I find the error messages and suggestions quite useful. Just because the compiler isn't invoked on the command line, doesn't mean it's not a compiler.
(source: theeggeadventure.com)