ann

Interview Andre Groß

In­ter­view with our Head of Soft­ware De­ve­lo­p­ment: An­dré Bahrdt

Wel­co­me to our la­test edi­ti­on of our se­ries Em­ployee In­ter­views, whe­re we dive into the per­so­nal ex­pe­ri­en­ces, chal­lenges, and in­sights of our team mem­bers. Meet André, our Head of Soft­ware De­ve­lo­p­ment, and learn more about his per­spec­ti­ves in the field.

What’s the big­gest mis­con­cep­ti­on peo­p­le out­side the field have about soft­ware de­ve­lo­p­ment?

That soft­ware, au­to­ma­ti­on, or even AI can ma­gi­cal­ly sol­ve every pro­blem quick­ly and ea­si­ly. In rea­li­ty, soft­ware de­ve­lo­p­ment is more of a sup­port for pro­ces­ses and/or users. But that only works if you re­al­ly un­der­stand and ques­ti­on what you’re do­ing in the first place. Other­wi­se, you’re just do­ing the same thing, only on a com­pu­ter in­s­tead of on pa­per.

Loo­king back, which tech­ni­cal de­cis­i­on cau­ses you the most hea­da­ches to­day?

Ho­nest­ly, none. Every de­cis­i­on made sen­se at the time it was made. What mat­ters more is lea­ving room to re­vi­se de­cis­i­ons la­ter if nee­ded, that way you avo­id fu­ture hea­da­ches.

How of­ten do you have to com­pro­mi­se on code qua­li­ty to meet dead­lines or other de­mands?

It re­al­ly de­pends on the si­tua­ti­on and how well you com­mu­ni­ca­te. So­me­ti­mes you just throw so­me­thing tog­e­ther quick­ly be­cau­se it’s only nee­ded once. In tho­se ca­ses, you don’t have to hold it to the same stan­dard as a pro­duct you’re sel­ling. It co­mes down to com­mu­ni­ca­ti­on and weig­hing cos­ts and be­ne­fits, and of­ten there’s a way to ba­lan­ce both si­des so everyone’s sa­tis­fied.

What com­mon prac­ti­ce in soft­ware de­ve­lo­p­ment would you most like to get rid of?

The ten­den­cy to think only wi­thin your own litt­le box. The­re are lots of ex­perts in spe­ci­fic fields or tech­no­lo­gies, but they of­ten stop right at the edge of their spe­cial­ty. Loo­king bey­ond, col­la­bo­ra­ting or even just ta­king a peek at what others are do­ing, is avo­ided. And that crea­tes fric­tion and pro­blems that don’t re­al­ly need to exist.

If you could run a soft­ware pro­ject with no time or bud­get cons­traints, what would it look like?

Pro­jects like that re­al­ly de­pend on the pas­si­on and cu­rio­si­ty of the peo­p­le in­vol­ved. Wi­t­hout that, they tend to lose di­rec­tion and fizz­le out. Per­so­nal­ly, I ac­tual­ly en­joy the chall­enge of working wi­thin cons­traints. Try­ing to de­li­ver so­me­thing wi­thin a set bud­get or dead­line, while still hol­ding onto your own qua­li­ty stan­dards, is whe­re I find the work most ex­ci­ting.

What a powerful re­min­der to think out­side the box, in soft­ware de­ve­lo­p­ment and bey­ond!

Thank you for sha­ring your va­luable in­sights and ex­pe­ri­en­ces with us. We’­re ex­ci­ted to con­ti­nue our jour­ney of #Rethin­king mass spec­tro­me­try tog­e­ther.