I’m spinning this off of here to limit the hijack. My title is Software Engineer, and I’ve been working in industry for a little over two years. I graduated from Case Western Reserve University with a Masters Degree in Computer Science.
I know there are other engineer/developers on the board, and I’m interested in how their answers compare to mine, so please join in. I have some questions for other developers to start with:
How are schedules set in your comany?
At my company, the developers are given specifications and are asked to provide estimates. If there is too much estimated for a release, features are moved to a later release. Management is very good about not pressuring developers to change their estimates
Roughly, what are the titles in your company? How do they map to responsibilities?
Here we have developers, engineers, and architects. Developers and engineers are pretty much synonymous. Both are responsible for low to mid level design, the vast bulk of the coding, and some testing. The ammount of testing done before quality assurance takes over varys from programmer to programmer.
Architects are responsible for the big picture. They ensure that we’re building something that’s valuable, and that the pieces fit together. They also validate designs from engineers and have veto power on technical decisions.
We have pretty much the same title structure as your company, although we don’t have developers–just engineers.
Our schedules and budgets are more or less made up. We’re getting better (and quickly), but for the most part we’ve been pretty fast and loose about that sort of stuff.
“90% of any person’s attraction to/love of/belief in/evangelizing of a particular language/platform/OS/piece of software is about their temperment, not the object’s intrinsic virtues or flaws.”
Agree or disagree?
At my employer, there is an IS department of six, including myself. One IS clerk (who handles routine tasks like downloading and uploading EDI transmissions, sending invoices/ASNs, and managing assets); one EDI administrator (setup/maintenance of EDI relationship with customers), two systems engineers (software development), one sysadmin, and myself, the manager, who doubles as a systems engineer.
Scheduling is the result of a negotiation with the requesting party where I balance my employee’s workload with the urgency of the request, sometimes altering the initial request, sometimes altering my employee’s priorities.
We’re a manufacturer with a homegrown system, so all development is internal.
Mostly agree. I wouldn’t use the word “temperment” since that implies the preference is inherent in the personality; I think that what someone is most comfortable with is what they espouse. I’ve never seen someone passionate about a specific technology because of an objective evalutation.
Our company makes automation software for programming Programmable Logic Controllers, as well as information systems for factories and SCADA software.
We design using lightweight design methodologies like extreme programming. We collect lists of desirable features for the next release from marketing, then we sit down and go through them and try to make sense of them and put them together into a coherent design (eliminating conflicting features, or ones that don’t fit the theme of the product, or whatever). The features are written up on 3x5 cards, and given to marketing to order from most desirable to least desirable (we used to just ask them to grade them, but of course 90% of the features came back as ‘Most desirable’…).
Once the features are ordered, we go through them estimating the time required to build them, with upper and lower limits. The lower limits are added together to give us a ‘best case’ number for which features make it into the product. The high estimates are added to give us a ‘worst-case number’.
As development continues and features are signed off, the actual times are added and subtracted from best and worst case, and this causes our best-case and worst-case lines to move, so as we get closer and closer to ship time, those lines get closer together giving us a continually improving accuracy. Theoretically, the two lines should touch togther on release day.
Features are broken down into ‘stories’, which are small coding projects that should take a developer a couple of days to do. Longer stories are further broken down into a series of tasks.
We built our own software tracking system which contains all the stories for the current release. As developers finish stories or tasks, they log on to the intranet and enter their start and finish times, which automatically updates our status pages. Anyone can log on to the intranet and immediately see the current status of all projects, which features are done, how far over or under schedule we are, etc. It all works pretty well.
All the stories also have sections for QA, help, etc.
Sam, we’re experimenting with XP, and one of the issues that keeps coming up is what the role of Quality Assurance is. Could you say a bit more about how your stories involve QA and help?
Well, we’re not doing ‘pure’ XP. Ideally, you should develop your test framework first, which makes sure that you have your specifications right and accounted for. THen you develop to the test framework, and you’re done when all your tests pass. Then the test framework goes into an automated scaffolding that runs regularly and tests all features of the software. The QA’s would be responsible to validating the coverage of the test frameworks, running them, setting up build machines, etc.
In real life, time pressures seem to constantly prevent us from building test frameworks. This is a bad thing, IMO. XP without solid test frameworks is essentially organized hacking, which can work on smaller projects but can bite you when it comes to more complex stuff. Still, we’re making it work pretty well.
In our shop, We go through several phases - First, a feature design, which gets reviewed by the team lead. The design is then handed to the QA, who builds test cases (often, the developer does this with him). Developers build their code and test it. QA’s are NOT supposed to be the ones to initially test the software. When the developer turns code over for QA, he has to show that he believes it has been tested and is bug-free. The QA is there to validate this claim. Of course, lots of bugs are found, and that’s to be expected. But if the bugs indicate that the developer never really tested his own code, it gets thrown back to him to do a better job.
I should add that we do one thing which keeps the software working right and which probably allows us to get away with our looser XP practices: We run build machines, and our software gets built every night. Then it runs against a smoke test which tests critical features and makes sure the software is working correctly.
In theory, our software should be ready to ship at any time once it’s passed its initial construction phase. If the build breaks, the offending code is removed and the developer who checked it in goes back to the drawing board. Daily builds are critical to quality. We’ve noticed that if the build process gets screwed up and builds don’t run for a few days, the quality of the new code goes down dramatically.
I have applied to Case Western in CompSci. How hard was it to find a job? Are you good at Calculus? How often do you use Calculus in the ‘real world’? How much do you make? What’s the work enviroment like?
as far as schedules go, we’re all salaried employees, and we are all quite committed to the jobs we do. many people take their work home with them, and it is never asked of us. most people work about 40 hours a week, usually from 8-4 or 9-5. some people work more, when something is needed.
i work for a research and development group developing (a) computer-assisted orthopaedic surgery system(s). we’re associated with carnegie mellon university. a lot of our work is research, more than software development. i think everyone’s (but me) title is more-or-less “engineer”, and we all do software and hardware development, as well as research. the process generally consists of a project being named and someone saying “i’ll do it”, based on the projects they’ve done in the past. my personal project has been development of a sound library, so everything associated with that, i say “i’ll do it”. i also work on patient data preparation software, since my job is supposed to be to develop the operative process. we are a pretty small group, which is why i think everyone does everything. there are several (european) groups in our field who have enough employees to have a genuine development process, and i guess that’s why they have commercial products out and we only lead the way scientifically.
anyway, my questions:
one of the major things we are trying to work through now is FDA approval. in order to do that, we have to have many very specific processes in place. we have to document each of those processes. so, do you have to document the design process? if so, what methods do you use? do you do design review? actual code review?
as someone who’s spent a lot of time working on linux sound programming, is there a comparable thing for windows? is windows sound “device” oriented, where you write the bytes to a sound device? do you know of any decent web pages that provide the necessary information?
what platform do you develop on? in what language? how much of your education was dedicated to general techniques (data structures and algorithms), and did you find you had to learn a LOT of language nuances when you actually had to program some applications?
when you and a bunch of co-workers go out to lunch, and you talk about how static declarations in functions only get processed the first time through the function and the like, do you feel embarassingly dorky?
finally, where did you do your undergrad, how hard was it to get into the masters program, and if you knew people do you think it would be easier?
Good luck with your college search. Case worked out well for me, and I hope it does for you if you go there.
I got perposterously lucky finding a job. A professor I worked with recommended me for an internship, and I got a job offer there before the summer was over. I liked the place enough that I didn’t bother to do much searching.
I enjoyed Calculus in school, and was good at it. I never use it at work though. If you aren’t enjoying it at school, don’t worry. Calculus is handy to know, but a lack doesn’t shut off career paths for you.
I’d rather not talk about how much I make. I took a quick look at google and there are a bunch of salary calculators out there. I don’t know enough to be able to recommend one.
I don’t know what you’re looking for with work environment so I’ll free associate. It’s changed quite a bit in the last few years. When I started, the kitchen was stocked with candy, cookies, soda, and microwave dinners in the freezer. Naturally, this didn’t last. As a cost cutting measure we’re down to free sodas. We still have individual offices in this branch, though other locations have cubicle farms. The best part about the work is the co workers. I respect my co workers, and trust that if someone is asking a stupid question, I probably didn’t understand it. Management also respects the workers here. We’re able to work from home if our responsibilities allow, and are given great flexibility setting our hours. I’m sure that as soon as some tool abuses this policy, we’ll all lose the privledge, but until then I’m happy.
It’s not always a worker’s paradise of course. Some days I’m frazzled by the ammount of garbage I have to put up with, same as anyone else. Some days I get bombed by management, when I learn that everything I’ve been doing for the last two weeks is wrong. Other days I want to go home at lunch and never come back. Mostly though, I’m happier working here than I would be anywhere else.
We produce information integration software for Biotechnology/Pharmaceutical companies. This doesn’t require FDA approval, so we’re quite a bit looser than I imagine you have to be.
Typically, we work in one to three man teams. The person responsible for a component draws up a design docuement for it, and we iterate through design reviews. Attendees at these reviews are people who will work on the component, architects, people who will interface with the component, and pretty much anyone else who’s interested. The documents are publicaly available within the company, and the customer may wish to see them.
We have done code reviews in the past, but they are uncommon. When I was an intern, my group’s code was reviewed since we were all new to the company. Partially it was to raise the code quality, but it was mostly a teaching tool. I wish that we did more reviews like that, but we can’t afford the overhead.
**
I’m out of my depth here. We don’t have sound in our product line.
**
I develop in Java, to Sun’s VM. We support linux, some flavors of unix, and windows.
**
In college we pretty much programmed C in a C++ environment. Probably 90% of the computer classes were teaching general techniques, if you were willing to look for the generalization. I found the transition to Java pretty easy once I was spending eight hours a day at it. My co workers helped me out, but I’m still finding things in Java that bite me.
I have a favorite quote from Neal Stephenson that I’m sure you have come across before:
But no, I’m not embarassed by talking shop. If there’s someone who isn’t interested in the subject, I try to draw them into the conversation, but that’s not limited to programming. I’m a dork of course, but not because I know the difference between StringBuffer.toString() and StringBuffer.substring(0); I’m a dork because of who I am and the other bit is just a way to capitalize on it.
I did both undergrad and masters at Case. They offer a five year combined MS/BS program that you sign up for if you like. It let me take more interesting classes, and I had a cubic buttload of AP credits, so I figured what the heck.
Despite its evangelists’ pleas to the contrary, there are some things Windows does better than Linux simply because (A) Windows was designed from the ground up to be a GUI environment, and (B) one company controls all of the Windows O/S standards. Audio capability is one of them. Windows has a whole “Multimedia API”, which includes full waveform audio capabilities; c.f. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/wave_7jcf.asp if you don’t have the Visual C++ helpfiles.
I work in a small company with 7 employees, and I do the vast majority of the software work myself. We focus on research, and usually we either sell a whole technology (including hardware, software, and services), or we write software for ourselves and only sell the services.
Rapid development is usually more important than bulletproof or user-friendly applications. We use Delphi for Windows apps because it’s quick to develop, quick to compile, easy to reuse code, and lightweight enough that we can install it on several machines. When a bug crops up in the software that controls an important device we need to use right now, I can have it fixed in a couple minutes if Delphi’s already installed.
How are schedules set in your comany?
I’m given a general spec and asked for a time estimate, either by a coworker or a client. If the estimate is too long, we’ll try to simplify features, or defer them. Everyone juggles a few projects and the estimates take that into account, so when a deadline comes up (e.g. we have to show something at a conference), it’s easy to shift time to higher priority projects.
Roughly, what are the titles in your company? How do they map to responsibilities?
Software engineer (myself) and hardware engineers. The hardware guys build circuits and write code for microcontrollers, and occasionally work on my applications when something breaks and I’m not there.
When we collaborate on an embedded system, they basically give me a spec of what needs to be done, and a description of which hardware is accessible. I have very little electronics experience, so all I know about their hardware is whether or not I can make it work.
How concerned are modern SE’s with the speed and elegance of their code? Do people bother writing highly optimal algorithms or do they only try to optimise if the program doesn’t run “fast enough”.
I try to focus on the big picture and let the compiler figure out the details. When my program will never run on a computer slower than 300 MHz or with less than 64 MB of memory, there’s no reason to wring out every last clock cycle or byte of RAM–an hour spent thinking up a more efficient overall approach will pay off a lot more than an hour spent optimizing line by line.
I tend to just get the app written, then use a profiler (*) to find the parts that would benefit from optimizations.
or the poor man’s profiler: give the program a lengthy problem, let it run for a few seconds, pause the debugger, and note which function it’s in… then repeat until you get an idea of where the program is spending most of its time
At this stage in the game, the most important thing is that your code should be intelligible to people who didn’t write it. Efficiency is a close second, but it’s much more important that some other engineer can pick up your program and understand it.