More on Refactoring & Software Teams

I've had one of those moments where I have posted and just feel the need to elaborate on the topic, I enjoy that feeling, so here goes.

I posted about prototyping and that is such a very loaded word and indeed quite a broad subject, I'm not delving into anything specific in that field; however I am going to talk about my intent in why I enjoy revisiting, refactoring and the benefits I have found with those efforts.

First, refactoring, itself a simply enough principle, you can both simplify something and make it more readable, more maintainable, you can also refactor to take advantage of new advances from other technologies; perhaps a new library, or new framework, which achieves the same effect as your code written by your (perhaps) smaller team; and in my opinion going with a library written and peer-reviewed in use with hundreds, thousands or even millions of other users is really a boon to your assurance of its use over your own individual effort.

[Yes, writing your own can also be good].

 Second, revisiting, this is really the meat of the prior post; going back to your own code, or code in another part of a large system, write it your way, update the coding standard, conform to emerging or simply new best practices.  Doing this is really quite interesting, and you can through the magic of software do it side-by-side.

You can refactor the function "foo" with your own "bar" then simply swap the two function names and voila the original system process flow now uses your new code, and you can test it, try it and crucially roll back if you need to.

This is a great tool and the real reason I wanted to highlight the practice.

It isn't just limited to individual benefits, it can benefit team members around you, to both have the practice demonstrated to them and used as a catalyst to encourage them to engage with the code more widely; too often I see engineers rabbit hole into a single field, or become the defacto owners of only one vertical slice of a code base.

Such occurrences can lead to friction, what happens if they are absent through say illness or holiday, a problem occurring in their field becomes very important, the pressure ramps up on them, on the team and ultimately the project.  And there's no pressure value to relieve this, you rely solely, heavily, on that one person.  What happens if they do not like this work environment?  You are unable to support them!  They feel they are trapped!  There are so many negative effects from the sole-engineer/owner model that again I am beginning to touch on a whole other field of the software engineering puzzle.

So refactoring efforts to me become a way to familiarize multiple engineers into the general planform of a project, large or small, it helps each engineer support every peer in the group; they find common things to discuss, or collaborate on.

To me, working through a codebase, as a group, in cooperation is really important.

And it starts with one person in front of one screen tinkering and discovering. 

Developer : Being the Outsider

As someone controlling projects it's sometimes hard to get into the action with others around me, the best way is to talk to those people, to be involved to offer anything you can; perhaps not opinion, but fact to start off with.  Over time working with people this way I've always found you are invited into the more intimate meetings, the nuptials of the project, if you will.

This is a natural, human, process.  Great, or grand, projects such as Nasa's probes to the outer planets in the 1970's had much press attention, indeed some projects such as Nasa'a Magellen probe of the 1990's had press not only present, but directly interacting with the engineers and scientists (and then writing excellent books - "The Morning Star" by the late Henry S F Cooper anyone).

However, the mundane and private enterprise contains projects of a lot less public interest, indeed they are private interactions.  And if as a member of a company you've not yet had time to foster those friendly interrelations to gain constructive access to the meetings about a project you do find yourself as the Outsider.

You can hop and jump and try to peer through the murky world of hints and conjecture, but without getting up and digging into the project this can be hard work.  You may just want to help, but those inside the project might perceive you as stepping on toes, or going beyond your bounds of responsibility.

This is where the management have to see something, if you're already in a position to approach the project as a higher grade or manager role and offer yourself into the loop, that's easy and relates back to building bridges.  But if you're not, management have to recognise and apply you to the project.

Beyond team membership, stepped aside from the scrum master, and not overarching the product owner; to use the right buzz words, that is you have to literally be a fly on the wall and then slide yourself into position to help, rather than hinder.

How you do this is dependent on the people, you can offer code review, document review, hints or tips on hardware or architecture.  You can assist the team members or scrum master, even getting a round of coffee in can be that little bit which helps keep the folks on track.

But without yourself oiling the cogs of development with presence, approachable and an obvious willingness then you will likely remain the Outsider, you won't be on the ground floor for development meetings, you won't be in the loop with e-mail about project, you won't even know what is going on around you.  If you end up in this situation, you need to address is up the chain, to push for somewhere to help yourself fit.

You always need a good manager above you to help with this, and in return you need to help them in order to help yourself.

WarThunder - BF109-E3 & BF109G6 Matches & Teams

My strategy in both aircraft has basically been the same, climb for altitude off to one side, then fly at a shallow climb into the combat area, at the BR3.7 and below range I find everyone doing the same thing, we get wins, we get kills... So fun has that been, and so successful I've unlocked both the skins for the E3...

So, I jumped up to my next unaced 109, which is the G6.  Here's my progress on the modules:

And things are not getting any better, it's agonisingly slow to unlock anything, because either I'm shooting and hitting Russian aircraft and they put out their fires (scouts honour, I've hit La-5, Yak3 and Yak9's, had them burning as well as any other target - which would go down - only to have them put their fire out, and worse still they loose no fighting ability).

Now, I refuse to believe these players are excellent, in fact in the last game they were good to average opponents, but my team going into them was abysmal, first off, the German team, aside from myself off to one side and two chaps in the middle failed to climb, so straight off we're playing 9v9 and two thirds of our planes are at lower altitude... Next, they enter turning low level fights with lend-lease P39's, Yak9's and Yak3's.

At altitude, I'm coming into the combat zone at 5,500 altitude, 300km/h and looking for a target to dive on, by the time I'm there though there's only two other members of my team left and I have to dive into and through the whole enemy team.

760km/h screaming down on a Yak3, he's going a good 550km/h, my controls are stiff, but I'm waiting for him to try to duck under my guns... There, he ducks, I swerve... My shells totally miss, because of course even now going 600+ the guy looses no control, he can pull a tight barrel roll and rudder control it... I'd be in g-lock "Lost Control" doing that, but not he, for he has ghost of Comrade Stalin blowing into his belly button to keep him upright.

I pull up and away, not wanting to turn, 760/780km/h indicated, I pull up... from 30m alt.... 1600... I'm already down to 300km/h speed... I look behind....

Yes, that's the whole entire enemy team on my six now, and you see that La-7, he's closing that gap with me... But he was closing that gap even when I was going 700km/h.

I'm dead, and this is the annoying thing, I didn't do anything wrong... Diving into the fray at all was my mistake, I should have stayed at 5.5K, climbing to flyaway and live to fight another day.

Whenever I fly against Russian aircraft the same can only be said, I don't get kills, and I get killed.

I don't know, after a month of solid flying the American and German lines, maybe I need to take a leaf out of Tsung Tsu's book and get to know my enemy?  The problem being I don't have much advancement in the Russian aircraft line, since I dislike them, nearly all my vehicle progress in the Soviet tree has been tanks.

The overwhelming conclusion I have though, is that many players at the higher BR rating have either not learned how to energy fight, or don't realise they need to energy fight Russian planes, so I find myself alone and out numbered nearly all the time.

I've been trying to check this on different servers, EU, US, SA, RU... All the servers, it's not the players, it seems to be the match up, at the higher BR playing Germans in Realistic battle I get bad teams.

And this isn't to say I'm the best team member to get, but at least I try and climb, I try and get energy, and then I try to find targets, but then those targets are already in turning fights at sub 1000meters, it's a hell of a waste to have gotten to 5000+ meters, and even more of  a waste to dawdle all the way down to try and attack, they already know I'm there, and they're far more manoeuvrable to dodge out the way.

Successes are few and far between in the G6 and above, in the E3 they're plentiful and fun... The difference?... BR and the teams at those BR's.