Related
For the past few years I have been taking all of ESRI's free Moocs but I want to get more hands on a creative experience without having to shell out thousands of dollars to take the courses and certifications. Working with maps and especially the idea of bringing new eyes to existing and worsening problems is a life long goal of mine. Any help would be appreciated, The Moocs just give a basic overview of the software functionality and there's not much room for creativity or to work on problems dear to me. If anybody could direct me to some legit resources I will owe you my life. I am currently learning Python which I know will help with the customization of functions and whatnot, but I must admit I'm more on the beginner's side now.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I was wondering... There are people out there who code stuff going to mars, satellite control systems, nuclear facilities. What kind of training did they do ? What is their career path ?
I have a friend who, after graduating with a BS in optical engineering, went to work for Perkin-Elmer, grinding among other things, the Hubbel mirror. In his free time, he wrote software to calculate the trajectories of earth projectiles and teaching himself orbital mechanics. His interest and accomplishments so impressed people at NASA that they hired him and his career included managing SW development for the space shuttle simulator and acting as mission specialist on a couple shuttle missions.
I have had discussions with people working at Los Alamos National Laboratory and they say that in order to work there, you find someone who already does and then call them every week for at least two years and that may lead to an interview.
In other words, be interested and persistent.
A counter question - are you talking about R&D or production code?
Alot of the answers above apply to the R&D teams developing new ideas to enhance existing inventions, or to enable new scientific adventures that were not previously possible - in those cases I agree.
But there's still a slew of people writing the code that actually gets deployed with the hardware. As with any major endeavor - you don't want the visionary dreamers who came up with the radical solution to be the guys actually implementing the thing that could risk human life. It's two different focuses and two different careers.
I agree with the Academic, research approaches you're talking about the R&D teams.
But if you want to write the production code, get familiar with process and quality control and assurance practices. All of the fields mentioned involve development contracts with the government which will require the highest degree of due diligence and care, since they cost huge money, may risk at least a few human lives, and in the case of a nuclear facility - they could destroy entire populations. You want to make sure that code went through plenty of review and testing!!
To get on the development teams, learn some of the high end development processes and practices - CMMI, Six Sigma. Learn as much as you can about testing and lifecycles. Work in an internship close to this field, particularly if the internship will submit you for a clearance - a lot of the work you mentioned may require defense clearances, and it's a huge leg up if you graduate college with a clearance in hand.
There are dozens or perhaps many dozens of different types of jobs involved. Some do more physics, simulation, GUIs, command and control, and so on. Is this question "How do I get started down this career path?" or "I'm curious, who are these people?"
Those type of fields require an education (probably through at least masters) in Physics and Mathematics, where programming is a secondary skill.
The typical path probably looks like:
Get a student job in a University research lab
Learn from the "old" graduate students and employees
Get hired as a temporary employee in said research lab
Teach the "new" graduate students
Do something good to get noticed
Make contacts with people in the granting agency
Get hired by the contracting agency or one of their contractors
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 months ago.
Improve this question
I've been working as a software developer for almost a year (not much though) in a corporate environment but all I've done so far is a raw software implementation of company needs. Senior coworkers don't seem to be doing some fairly different stuff. In fact their "benefit" for being experienced is simply an app design and getting their hands on new projects first. My elder software developer friend's jobs don't seem to differ from the overall picture.
Currently I'm a student of a CS department and what I really want to bring in this world is some innovative(not new but innovative) stuff that haven't been there. Something as great as google wave or JARVIS (if that can be done at all) or even much better, but yet it looked like that's not possible. The question is: when do people in a corporate environment choose to create something innovative? (from your experience/thoughts)
These are your options:
A) find a company that does something that you like
B) Find a company that gives you time to do your own thing
C) do your own thing at home
Notable innovation usually only occurs at a few select companies (Google, as others have said, Microsoft, though they're not doing it as much, and Apple). However, the main thing for an innovative program comes from just an idea.
Can you think of something others haven't done? Can you do it? Will you do it?
If the answer to any of these is no, then you're not going to be the guy coming up with "The Next Big Thing". It only comes from having an idea, and doing something with it. (I read something about this recently, I think from Joel, but not on his blog. Anybody know the article I mean?)
Unfortunately, working in a corporate culture, unless that corporation promotes new ideas (see above), you're going to be stuck doing the same crap as everybody else. I know for myself, I spend all day in front of a computer, looking at code. When I get home, I keep meaning to work on my own "innovative" idea, but I play video games, drums, with my dogs, go to the gym, hang with friends, whatever. I have no desire to spend yet another few hours in front of a computer working on more code.
The same thing happens to a lot of people, and unless you can get past this, you're never going to build something.
So, simple answer: When you have an idea, and actually do something with it.
Most of the time, the answer to your question would be never.
The motivation to go off and do something innovative is entirely dependent on the person. When it comes to typical corporate America, I wouldn't expect to be creating anything innovative and amazing. I would say the majority of anything truly interesting and innovative happens after hours on their own time if the person in question has a real job.
what I really want to bring in this world is some innovative(not new but innovative)
Don't we all. Sigh.
If you're actually brilliant, you'll have opportunities to do this. "working as a software developer for almost a year" Remain calm. The "long run" is 30 or 40 years of a working life.
If you're like the above-average people I've met, you'll be just able to produce software that's good enough to help your company get ahead. Until dumb management subverts things.
If you're like the rest of us, you'll spend your career struggling to chase after the above-average folks.
For the most part, software innovation doesn't happen very much in environments such as yours, and when it does it is usually done as a "skunkworks" project without official management approval. If you want to be involved in innovative work your goal should be to eventually work for a software technology company like Google or the like, or you can just join one of the many open source projects out there. Doing the latter is a good way to build credentials to get a job with a more interesting employer.
It shows when you can prove you have a market for your innovative software. Have a proof of concept ready and be prepared to defend your idea. If it can really bring in the cash, it will catch someone's eye. Ideas that are provocative yet fail to gain any financial support remain to be followed in your own spare time.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Our company has been thinking about scrapping our interview procedures and bringing each candidate in for a 4-5 hours sit-down with some of the programmers and just do some pair programming.
I like the idea in theory but I am not sure how you can really make it fair for each candidate. How would you rate them? Wouldn't their input really depend on what each programmer was working on that day?
Any thoughts on whether this is a good idea/bad idea or how to make it work is what I am kind of looking for here.
Cheers!
EDIT:
RESULT - AS requested
We are going to conduct the first steps of the interview the same as before. Phone followed by face to face. Instead of bringing them back for a third and final grilling, we are going to bring 3 developers back to sit with all 7 members of the team. We have decided to let the team decide who is then hired.
We have come to this conclusion for a couple of reasons. We believe this will empower the developers by giving them a choice who they are working. The second reason is group dynamic. We think it is really important to have a good group dynamic and it is hard to tell until after you hire a person if they will fit in or not.
So the end result is we are going to go ahead with the pair programming sessions but in a completely different way and for a completely different way than was originally intended.
Any thoughts or criticism of this approach is more than welcome!!
(this edit is posted as an answer below so feel free to downvote if you feel this is not the best approach)
Unless you use pair programming extensively in your real-world development, I'd be very hesitant to use this. I've met any number of high-quality professional developers who have mentioned a strong aversion to pair programming and whose skill would not be well-judged in such a process.
I hope you have a bunch of steps ahead of this one. For this to work you need an excellent resume and phone screen. You don't want to spend oodles of time on candidates that you shouldn't be talking to in the first place.
So you suggest an initial interview
and possibly have the second interview
as the pair programming session? – Ted
Smith (1 min ago)
Yeah. You might even think of having a simple coding interview happen over the web using something like CoPilot.
The easiest way is to give each person the same programmer to work with and the exact same piece of code.
The problem you're going to run into, is that hiring isn't like programming. There isn't a step by step process to lead to the right answer as to who to hire. (you can have multiple steps to make the decision easier). You have to evaluate each one on their strengths etc. and essentially make an educated guess as to which is the best one to hire. Sometimes you guess wrong.
The other thing about pair programming you're going to have to watch out for is the amount of time necessary to have each candidate at that stage go through that kind of a test. If I were looking for a job, I would be hesitant to go an interview at a company that would ask me to do that. Why? Because that is a lot of time, and if I am interviewing at multiple places, I could spend literally days just going to interviews for jobs I may not even get or want. Someplaces like Google or MS would be an exception, but most places are not like those two. (Not to mention the fact that if they are working on real code, you are essentially asking them to do someone's job for free).
As a personal anecdote, I got smacked around in an interview because of a technique like this. I had gone far in their interview process; passed the resume checks, the code submission and this was the face to face portion of the interview.
I was fresh out of university and had never pair programmed before nor done TDD. They sat me down to do a deck of card exercise and it flopped. Badly! I didn't understand why the interviewer was writing tests that seemed so dumb* (IE "return null;") and they didn't explain why and of course being foreign to TDD I didn't know what questions to ask. The end result was that it looked like I couldn't program my way out of a paper bag.
If you're going to do this type of exercise you need to cater to the interviewee because they're going to be in different spots with their aptitude. This means that you'll get different assessments that may not be based on actual talent and are thus going to be heavily biased.
**Now that I understand TDD, I do understand tests like this and how it's supposed to work, but man did that ever seem stupid at the time!*
I just had an interview with a San Francisco based company that prides itself on Agile methods/etc. I was to interview the CEO himself. I have about 20 years of experience in the industry, but have never pair programmed or developed using TDD approach. I was told it would be a "programming interview" but had not idea what to expect, and before we started the guy said that he thought that I may agree that all interviews should be done this way. (which in retrospect was nothing more than an arrogant statement).
Anyway, at the interview the exercise was to develop a class using TDD. It took me a second to adjust my thinking on the entire process, again since I had never pair programmed or done TDD. While I stumbled here and there I did ok in the end. but his reply was the I did not exhibit the aggressive back-and-forth nature that they require for their pair programming environment. Now, that could also have been an underhanded way of saying that "I didn't think you did great" kind of message.
Luckily I didn't need the job and to be honest the experience made me realize that I'd rather find a different career than having to be a software engineer that HAS to work in pairs, day in day out, when it came to developing code. Odd thing is that on occasion I have worked with another person on code simultaneously, so anything is possible.
In end I guess it was a good outcome since they didn't think I was a good fit and I didn't care for their working methods. But we would have came to the same conclusion had I talked a for a few minutes more about myself and had he given me a little more info on how they go about their work. Which is to say that there are other ways of finding a good fit candidate than putting them through the stress of pair programming with a complete stranger; bogus way to gauge competency imo.
One particular company uses a technique called extreme interviewing. For the extreme interview they will bring in say 30 developers and group them into 15 pairs. They will explain that they are looking for people who work well with others. That they will make a hiring decision based solely on their ability to work with others.
They will provide a problem for the pairs to solve. They will emphasis that they are not interested in the solution just each programmers ability to work with others. For each pair they will provide an observer of the pair. During the exercise (about 2 to 4 hours in duration), the observer will takes notes about a person ability to pair ... not the solution.
They are amazed how many programmers focus on solving the problem instead of collaborating. Of the 15 pairs, they will identify about 4 to 6 developers for a second interview. Those developers will be asked to come back and spend a week with the team (they get paid). After a week, they decide who to keep. Generally about half of them (2 to 3 developers).
When they are done, they have developers that are able to collaborate and after a week working with various pairs, the team has a strong indication who can effectively develop software. The process is both innovative and effective. They have had a high success rate with those they have hired.
I just had a pair programming interview a few days ago and to be honest, I don't really like it. I was notified of this a day just before the interview and then the interviewer told me that pair programming is what eventually I am going to do anyway in work. I went into the office and was paired up with someone who is a very senior software engineer. The company is in San Francisco and they are a well renowned company for pair programming, everyone pair programs in the office. At first it seemed to be fine, he explained about all the tools they used, their own unit testing framework that they build, and a bit of the project. He then basically wrote a bunch of unit tests and wanted me to work on the implementation to make it pass. Just as an FYI, the code base that already exists is huge, I would say 10k lines, it's not like a super complex project, but it is complex for someone to just step in and then write code without prior understanding of the class hierarchy etc. I find it really hard to believe that he expects someone to jump right away in a 10k line of source code that already exists. It just doesn't match for a pair programming interview, a smaller code base would help. I struggled a bit from navigating through the classes and going back and forth because I can't remember class names as I was overwhelmed by the amount of classes/code that already exists. To be honest, this really made me do horrible in the interview process. In the end I didn't feel really good about it. I haven't done pair programming before, mostly is just during assignments in my college year.
To me the power of pair programming can be harnessed if you're already proficient/comfortable with your pair, but is not really suitable for interview. Sometimes I would like to ask questions to my pair, but then I thought if I ask too much questions, then they would assume I were stupid and can't perform. If this was already on a real job, I wouldn't hesitate to ask, but in an interview it's hard.. you want to ask because your pair should help you out when you're stuck, but at the same time it's an interview, so you can't really ask much.
That is just my experience that I have from pair programming interview, my suggestion if you really want to do this:
be sure that you don't give the candidate to work with a large code base, work with a
smaller one and therefore he/she can show his/her skills to the max
be up front with the candidate before pair programming interview, can you ask questions
when you're stuck, should you be able to do this and that, what can't you do
be as detailed as possible
In the end, I wouldn't suggest it. It's hard to measure a candidate's performance in pair programming, and it might be biased as well.
I like this idea. However I think it might be difficult to do since it would require the candidate to have some knowledge of the project you would pair on with him. Also, 4 to 5 hours seems a bit long. What if you immediately see that it is not going to work out, are you going to sit through the whole session with the candidate?
Good question though. Stuff to think about.
Why not? Also, it's not like interviews are always (or ever) fair. You should evaluate the end results of the new approach against the traditional interview-based approach.
Also, a mini interview before the pair programming session might be good to keep from wasting the programmers' time with people who would be a bad fit.
From my limited experience, my feelings are mixed. I like the idea of pairing as part of an interview, esp. if the company uses pairing often, because it gives both a better feel for the fit. As a candidate, I've often gone through interviews where I sat in a room answering questions for a few hours, but afterward didn't have a good feel for what it would really be like to work in their environment. Pairing may be more beneficial than a random coding exercise, unless the interviewer is skilled at working someone through those. And I like being able to discuss technical stuff from both sides. And as a candidate, I'd rather interact with someone than just answer questions or solve code problems on my own.
But... as others have noted, the time needed can be an issue. I've gone through a couple days of pairing interviews and found some periods good, while others felt like a few hours were wasted: one because the developer wasn't working on something that lent itself to pairing (esp. given my background), the other because an env issue prevented much useful work for a while. If the job doesn't work out, it can be frustrating to have taken a day or two off work for this.
One place trying this approach wasn't sure if they should have someone outside the company working on a customer's project. They also worried that explaining the domain and work being done would take too long, though without that the candidate may not be able to contribute much. So they chose an open source project the employee was working on.
This seems to be a key point: there needs to be a well chosen task that the candidate can understand quickly and be able to contribute to. The latter part will depend somewhat on the candidate's skills. Also key would be the employee's ability to evaluate someone with this approach. Not everyone is great at normal interviewing, and that's probably more true of a pairing interview.
Also, if a company doesn't do much pairing then this kind of interview may not be as useful. There does seem benefit in seeing someone code (as Joel Spolsky notes), and this could be a good way to do that. But if pairing is not a typical part of the job, then perhaps a full pairing session isn't appropriate. Maybe a modified version.
I'd be curious what companies who have taken this approach think of the results. Reading some of the other answers to this question shows that it doesn't always seem ideal from the candidate's view.
To keep it fair, you'd have to make every participating staff member have a prepared problem to evaluate the candidate on. Preferably something taken form the real world in their company experience, but something that has already been resolved. This is a good chance to evaluate the knowledge on a problem and evaluate not just programming skills.
I hate it when too specific questions are answered. I had an interview once where a programmer was testing my knowledge of the STL which I used extensively and was trying to get me to answer that a custom allocator was needed. I had heard of them but never used them (esp in windows) and was made to feel dumb. IOW, avoid being judgmental.
So my point is, ask practical questions that aren't so much about testing programming knowledge as you can evaluate more qualitative personality and problem-solving approaches if you use the "pair programming" idea.
Good question!
Honestly, that sounds like a great idea, though Jason Punyon is certainly right that you should do a lot of weeding before you waste significant amounts of your developers' time on culls. You get a glimpse at an important metric out of it that's otherwise nearly unobtainable in interviewing: what someone's like to work with.
I don't think there's really any need to be concerned about it being "fair" based on the subject matter or trying to present consistent situations to different candidates, if you maintain the right evaluatory attitude -- that it isn't about whether they "got the right answer" or jumped through the right set of hoops, but what sort of effort, problem-solving, communication aptitude and flexibility they showed. You'd lose most of the benefit of the exercise by turning it into an artificial test, not to mention changing it from something that your developers can get some benefit from (or at least still get some work done during) to a massive waste of their time.
Joel Spolsky has an excellent Guerrilla Guide to Interviewing which talks about, amongst other things, programming tasks.
Trivia: Joel Spolsky is a co-founder of stackoverflow.com
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
What ever happened to Textmate 2?
I was almost positive that there was a post to the mailing list within the last 4 months that strongly implied -- or outright stated -- that there'd at least be a beta by summer 2009, but I haven't been able to dig it up, so I'm not sure.
To be honest, I'm not really that concerned about TextMate. Sure, I'd love to see it, because new stuff is always cool; but in my opinion there are only 2 big features missing from TextMate -- split-pane viewing and better undo support -- and I've found I can live without those. TextMate 2 will probably be awesome, but the current TextMate is such a great editor that I'm not anxious for TM2 to come out.
Update: A public alpha is due out by Christmas 2011.
Update: A public alpha is now available
From the wiki:
Q: Is TextMate 2 still in development, or has it been abandoned?
TM2 is being actively developed. If this text is still here, that is still the case. (Last updated April 7, 2009. Allan stresses that no release is "around the corner" yet.)
The author, Allan Odgaard, has updated the TextMate blog with this post:
Working on It
Over the past two years, posts on this blog have slowed to just a trickle, and a number of TextMate users have asked about TextMate’s status, or publicly worried about its future. This blog post, the first I’ve written here in a long time, is an attempt to assuage those concerns and answer some of the most frequent questions.
In short, TextMate development is going strong: TextMate 2 isn’t done yet, but progress is steady, it is starting to take shape, and the end is in sight. The rewrite has been a slow and careful process, but the ideas behind it are exciting. I hope to publicly describe some new abstractions in the coming weeks and months. Moreover, the community continues to churn out new bundles and features for TextMate 1.5, and I’ve been building up a backlog of posts describing them. While I am not writing to announce a release date for TextMate 2, I do hope that this post will be the first in a series showing a bit more transparency.
The requests for TextMate 1 have mostly been incremental additions such as split views, chunked undo, and editing over SFTP. But TextMate 2 is about more than new surface features. Every part has been completely rewritten to take advantage of the lessons learned from the years of version 1. Not only are the low-level data structures chosen for increased flexibility, but the abstractions on which TextMate is built—snippets, scope-based language grammars, context-dependent settings—have been rethought and are more powerful than ever. In the coming months, I’ll try to describe some of these new abstractions, but for now, know that I am excited about the new ideas involved.
So where does development stand for 2.0? It feels to me like most of the modules are getting close, say 90%. But as they say, on the horizon, mountains look small. While I use 2.0 for my own work, day-to-day, and the basic infrastructure is pretty solid, much of the front-end still needs work, and for now it’s all lacking the spit and polish of a finished app. Hopefully an alpha version will be ready before too long, but I can’t make any promises about dates.
And why haven’t I been better about keeping the world informed? It is a combination of many things really, but the main issue is that I am not good at writing for a large audience. I am more into informal conversations, for instance over mailing lists or on IRC. So while I started a lot of posts, I end up unhappy with them halfway through, and they don’t get finished or published. I am taking measures: I have enlisted a technical writer to help bring this blog back to life, and I’ll try to communicate more of TextMate’s status and direction through him.
Bigger than either of those problems though, as I mentioned, is that TextMate 2 is no minor facelift. It’s a major undertaking with a long timeline and its final form isn’t fully settled. I don’t want to hype vaporware, and I don’t want to get anyone’s hopes up before I know I can meet their expectations.
Furthermore, I haven’t wanted to throw ideas onto the internet without having a chance to implement them myself. I’m humbled that TextMate has served as inspiration for many other products, and I hope that it continues to be a model for other developers in the future, but I want to see my ideas done my way first, before I feed them to the competition.
I am trying to slowly turn this boat. With this post, I hopefully am showing that a hand is at the wheel. I know I’ve been quiet too long about my plans. I can’t make up for that, but going forward, I aim to do better.
And Here's the official blog post, saying the public alpha version will be release before Christmas 2011.
http://blog.macromates.com/2011/whats-next/
Allan Odgaard (Oct 24, 2007):
[...] there is no ETA, and I won’t speak
about timing before I am certain I can
provide an (alpha/beta) release within
the next month – because really, the
more I say, the more people ask, and
having to answer the same questions
over and over again is (for me)
mentally exhausting. So put TM 2.0 up
there with Duke Nukem Forever and be
positively surprised the day it is
released :)
Last I heard, it was in private alpha. Just remember: patience is a virtue. :)
Here is a recent post on a mailing list from author Allan Odgaard. It sheds a little light on the current state of development.
In short, don't expect anything soon.
Well it's been 1 1/2 years since this question. And no update. And no news.
I'm moving on from textmate. Shame really, cause it was the best editor on Mac. But, hell, even dreamweaver has passed it up.
TextMate author was hired by MacRabbit (company behind the Espresso editor) so it could be that Espresso will be the next TextMate (it's a real shame..)
It doesn’t say that anywhere in the article. Besides, this is simply not true. MacRabbit is also a 1 person company like MacroMates. Textmate's developer lives in Denmark; MacRabbit's lives in Belgium.
Expresso is a different editor, not Textmate 2.
I can scarcely believe this is true, but I just read that it is scheduled for release at the end of October, 2010.
http://wiki.macromates.com/FAQ/TextMate2
not exactly a direct answer to this question, but since I just signed up for an account and don't have the rep points to comment on an answer (or as it turns out include more than one hyperlink), I'll leave my response here for Paul and Vasil:
You should definitely check out Ciarán's ReMate Update plugin for TextMate as it has been invaluable for me while working with NFS.
I also highly recommend Ciarán's other TextMate plugin, ProjectPlus (ciaranwal.sh/projectplus)
One last plug for Ciarán...most likely due to the fact that he has developed some great plugins for TM1, he has also been hired by Allan (wiki.macromates.com/FAQ/TextMate2) to work on TextMate 2
There's really no excuse in the world that could convince that textmate 2 isn't vaporware.
Even if he was secretly coding the editor to demolish all other editors, the amount of years that have passed and lack of any real evidence of anything solid whatsoever, point toward poor development practices and lack of experience producing a product.
Unfortunately it looks like textmate 1 was a fluke, and texmate 2 is the software worlds chinese democracy...
I think its sad that this question remains one of the top Google search items when looking for TextMate 2 information yet it is filled with rumors and insinuations.
They are working diligently on it and what they are trying to do is so very very hard. Give them a break. I even wrote an article on this: On TextMate 2
A new post today with title What's Next on MacroMates official blog states (bold emphasis by me):
There has been a lot of speculation and trepidation about the future of TextMate recently, mostly about whether there will be another major release. Work on 2.0 began and while we wish it could have been completed faster we are very pleased with how it is turning out. Development has reached a point finally where we can make an announcement:
There will be a public alpha release this year, before Christmas, for registered users.
I am predicting, right now, that he is going to surprise everyone and give us a gift on Christmas of this year.
How perfect of an opportunity would it be for him release a relatively polished non-beta on Christmas and watch everybody in the world go ape shit.
Mark my words. 10 days.
TextMate author was hired by MacRabbit (company behind the Espresso editor) so it could be that Espresso will be the next TextMate (it's a real shame..)