hi, i'm looking at a position right now for a release engineer and i'm a developer. what kind of personality would fit best for a build engineer? is anyone here a build/release engineer full time that could share what they think of their job?
thanks.
I'm not a build engineer, but I can comment on our (former) build engineer.
Our build engineer was basically a developer who's skills weren't quite suited to being a good developer. Someone who has good attention to detail but doesn't excel at the problem solving skills used in programming.
From what I hear it wasn't a terribly exciting job, although there is a sense of power and responsibility that comes along with it. (Somebody with a big ego can wreak havoc as a build engineer, but somebody who takes pride in their work can be a huge asset in that role.)
Build maintenance and configuration management tend to go hand-in-hand. At a good place, you will integrate tightly with both engineering and QA. The most valuable personality traits in my opinion are "bullish" and possibly "domineering." Otherwise the engineers will run over you like a tank, and QA will burn your ass whenever you screw up.Originally Posted by bling
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Sometimes, however, this type of personality can mean the difference between your team getting a build out that day or not depending on the status of SCM and your build pipeline. SCM always seems to be in a state of flux which can make the build process a bit frustrating.The most valuable personality traits in my opinion are "bullish" and possibly "domineering."
If you are a dead set on being a developer this might not be the path you want to start down b/c it usually does not lead to development or allow you to do much development. You might be able to develop your own tools so long as they coincide with needed tools to get builds out quicker and more efficiently. And I would agree with Daved on the difference between a build engineer and a developer.
Last edited by VirtualAce; 11-15-2008 at 10:01 AM.
I worked closely with our Release Engineers the the other week, to allow the portion of work I and a few others in the company has worked on to be released so that the rest of the company and our customers can get access to the new functionality provided by the code I'd worked on for a few weeks prior to that.
I have the greatest respect for those guys. Their task is not an easy one. Managing the overnight build systems, tracking what works and what doesn't, raising bug reports when things "break" because someone has submitted code that breaks something (and it's not always obvious how it got broken - it may be a combination of things that suddenly cause a test to fail). As an example, when we released our code, all went fine into the pre-release branch, overnight build was the same as the "stable" branch. Then we let it into the "stable" branch - overnight builds failed here there and everywhere. It turned out that there was a setting difference in the stable branch for all the overnight builds, and all the drawing on the screen was upside down...
It is not, in our company at least, a developer role as such, but it's certainly a skilled role - and some troubleshooting type ability is certainly needed.
You shoudl also be the type of person that can keep track of many different tasks at once, and switch between them. Personal "soft" skills are also important, as you will be dealing with all sorts of your colleagues that will sometimes be quite stressed (because their manager has set a target that something should be released on day X, and it's now X+1 and it's not quite working well) and want something done "yesterday".
Knowing how to run a source/version control system and merging code from different places is another skill you'd need. It may not be your task to work out WHICH of two competing bits of code should actually go into production, but you certainly will need to know how to detect that such a situation is about to happen, and determine that "I can't fix this right".
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
thank you for the very detailed responses.
i'm just in a very confused state of mind recently...and i'm just confused whether the problem is me, my old supervisor, or just my job.
i had problems at my old job where i would disagree on certain things with what my supervisor was saying. even though whatever he decided in the end was what went, i ended up being labeled as a trouble-maker.
seeing as programming is such an 'art' with so many egos attached. i keep wondering to myself if i should just be the 'yes man' rather than trying to suggest better ways. the danger is there's always better ways to do it...and even more 'wrong' ways that still 'work'.
so then i figured maybe a build engineer position might work better with me, at least i don't have to deal with nit picking code disagreements....even though i'm a code monkey at heart. and in return i need to deal with people on a much higher level, which i might or might not excel at...
My sense is that you would have more of those issues as a build engineer, not less. That's a big part of that job - managing the developers and telling them what to do to make the build work.
If you enjoy programming and are good at it, then I'd stick with it. Not all bosses are hard to work with, even though there are quite a few that are. Make sure to also adjust your own behavior depending on your circumstances. If your boss never listens to suggestions, then stop making them and keep your eyes open to another development job. If your boss sometimes listens but usually says no, then pick and choose your battles. Offer your best suggestions as only that, a suggestion, and don't complain if the decision goes against you. Perhaps there really are good reasons that your boss isn't explaining well.
I have a hard time believing that you'd be labeled as a trouble-maker just for making suggestions (unless there were a ton of them) as long as you're listening to the boss's decision and not complaining. So if you are complaining are ignoring the boss, then adjust your behavior. If not, then don't worry too much. Things will get better, and in the meantime you can keep your eyes open to other opportuntities.
Depends when you disagreed, on what and for how long...
Constructive input should always be welcome, as it will provide a better way or validate the current path. All team members should feel that their ideas are valued for the team to function well.
Knowing when and how to provide input is the key.
Sounds like you may need to modify your style of communication with your supervisor. Different people communicate in differing ways. IME there are four basic personalities, each is motivated in a different way and so requires a different approach. [google]
Could be that a change in the way you communicate your concerns would have more effect.
Then again, one of you could be the problem......
"Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
Friedrich Nietzsche
"I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
George Best
"If you are going through hell....keep going."
Winston Churchill
basically, my boss was content with copy-pasting code rather than using templates or a base-class. my suggestion was rejected because it could "cause other problems down the line". this is just one example. eventually i stopped offering suggestions because i'd keep pulling my hair out from the answers.
as for personality types, i'd say i'm the dominant A type, and my boss is the steady C type. i like change and think agile development is great. my boss, from my experience, hates change and has told me he doesn't like agile development.
Last edited by bling; 11-24-2008 at 11:37 AM.
Your situation is interesting. I find that scenario all the time in my code. We have a huge codeline that has had over ten years worth of additions and features added on. Many of those have been added with a deadline bearing down and were hacked in rather than designed well.
We have a lot of code that is copy/pasted everywhere. Every time I paste a new version I curse and consider re-writing it to use templates or inheritance. Generally I just continue to copy and paste it. Usually the reason is that we don't have time to spend on re-doing it, although the "it could cause problems down the line reasoning" is sometimes valid if we're getting close to a release. You have to factor in the potential for regressions and the extra QA necessary in addition to the effort needed to refactor. If something works and has been tested, then re-writing it opens it up to a whole new potential for bugs.
Now, when I'm writing new code, I try to encourage my team to do it with an eye for good design. I've added templated functions so that I didn't have to copy and paste, and I've set up inheritance hierarchies as well. But that's all in new development where the same amount of QA and bug fixing will be required either way and where a good design will reduce implementation time.
And your comments about Agile are interesting. Our whole company moved to Agile development. Everybody except for our team, that is. We're not totally against change (we are adapting some principles of Agile), but for the most part we follow the same procedures that we've been doing for years. This can cause us headaches (like the copy/pasting) that get worse every year, but in the long run our product is doing the best in the company. We get releases out regularly and those releases have fewer bugs and fewer regressions than others in the company that have been heavily refactored or rewritten. We've had a lot of customers bail on another product because stuff that used to work stopped working after they re-wrote part of the code. Customers hate that much more than if a new feature isn't quite up-to-snuff yet.
Anyway, if the environment doesn't match your personality then it makes no sense to stay in that environment. But you should realize that there can be good reasons for you to follow your boss's decisions that benefit the company and the project you're working on.
That's interesting. One important idea of Agile development is test-driven development, and generally having a very thorough test coverage, so that code doesn't break. Of course, I suppose that whenever a team is pressed for time, it's the tests that are going to suffer.We've had a lot of customers bail on another product because stuff that used to work stopped working after they re-wrote part of the code.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
True, but when you write a large piece of code, inevitably there will be bugs. And if that large piece of code replaces another piece of code that used to perform the same function adequately, then some of those bugs will be regressions.
I'm not entirely sure what effect (positive or negative) Agile had on that situation, but they just had too many bugs and too much pressure to release and they ended up releasing a buggy product. Since they had made the decision to re-write code, that bugginess included regressions that soured the existing customers.
I'd say that in a truly Agile framework, you wouldn't ever release a "large" piece of code. The idea is many small releases (if not releases to customers, at least releases to internal QA) so that major development doesn't cause problems like that.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Again, I'm not completely versed in Agile development, but how would you do that if you were completely rewriting a back-end library in a new language for example? Sure, you'd release to QA often, but ideally you should be doing that anyway. That doesn't really solve the issue.
I find this interesting too, as our company is rolling out Agile in the whole development part of the company (roughly 1000 developers in differnet teams in some 5 or so offices across the world). We haven't started using Agile in our team yet - we will have our training after Christmas.
But if you are replacing a whole subsystem or back-end library, no matter what project planning method you follow, you'd have to have some sort of mechanism for choosing the new or the old whilst transitioning, right?
So, in Agile, you'd do a "walking skeleton" first, which isn't referring to supermodels, but means to develop something that "has the basic functionality, and no fancy stuff". Let's say we're developing a database frontend. The first step may be to support only data in string form, rather than strings, integers, float, date/time, bool and whatever else we may find as types in the database. And of course, the records would come out in the order they come naturally from the database withut any fancy selection, ordering or such. All other functionality that the full interface requires will return "not supported".
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
