Jim Lynch Codes
  • Blog
  • About Jim

Writings about one coder's stories & experiences.

Google's Programming Positions Applied to AngularJS

4/11/2016

0 Comments

 
I was at the book store today, and a book caught my eye that was titled, "How Google Tests Software". To my delight, it was a book about unit testing. But it wasn't really a technical book about unit testing with any specific testing framework. It was more of a book about how Google is able to break down it's huge offering of services into small areas that over and over ship quality software fast. Page 6 of the book talks about the roles at Google; the different programming positions you could apply for if you wanted to work there. I thought this part was extremely interesting, and I couldn't help but visualize how I was doing all of these roles of my current job. It would be an interesting thought experiment to scale out the "TDD developer role" across a few people, and I really like the elegant way Google does it. 

The Software Engineer (SWE)

This what most people think of when they imagine a programmer’s job. It’s what devs who don’t do unit testing think programming is all about. You want to build something- a game, an app, a website, and you get tasks that detail all the little parts of the finished product. You’re typing away, following the specs to build the thing that matches the product owner’s vision (which could be influenced by things like a/b testing or iterations of customer feedback, but ultimately someone has to make a decision about what things to prioritize). The software engineer spends almost 100% of the time at work coding. The author mentions that this developer does work in a TDD fashion and write unit tests, but testing is not the prime concern of this developer. It’s not much different in the Angular-specific world. This person should be familiar with Angular and have a basic grasp of how controllers, services, filters and the scope work as well as more advanced concepts like custom directives. Being familiar with the built-in Angular directives is key since this person will be writing a lot of html. This role would benefit the most from css / sass skills.

The Test Engineer (TE)

This TE position is the classic “game tester” persona and quality assurance person in many software companies. This is often someone who touches the application later on in the development cycle, but that’s not always the case. This person realy doesn’t need to be much of a front-end programmer able to build things with html and css, but instead will ideally have skills in browser automation (which just so happens to be Javascript in Angular projects). Selenium programming experience is huge in qa roles, and in particular for AngularJS Google has built a tool on top of Selenium webdriver named Protractor. Protractor tests are written in Javascript and look pretty similar to regular Jasmine unit tests, but they are used for integration / end-to-end tests and simulate the user physically interacting with the software.

The Software Engineer in Test

This is a very interesting role, and I’m very impressed that Google specifically has a separate job title for this. An engineer in test is almost 100% focused on the unit testing portion(s) of the codebase. This programmer is mostly focused on refactoring, working on unit tests, and increasing the test coverage. This dev often needs to understand programming even better than the software engineer, as he is there to help the software engineer become more productive by pointing out things that should be refactored and aiding in writing tests that the software engineer might not be able to or not do 100% correctly. The SET must look for not just flat out errors, but also clean up linter errors and code smells, a phrase used by Kent Beck and Martin Fowler to describe specific instances of things that should be refactored and how to do it. In an Angular project, this person is mostly concerned with the Jasmine (or Mocha) unit tests for a project. The SET would be writing more tests, refactoring existing tests, determining if coverage of tests is adequate, and helping the TE with protractor tests.

In Conclusion

I really do think these roles are excellent, and I would put good faith in any company that actually does develop with a team comprised of at least one of all three positions. I think the Software Engineer in Test is a pretty novel concept, and I’ve honestly never seen it in any of the companies I’ve worked for or had to the chance to visit. The author later mentions how senior management many times comes from the realm of program management and development so they don’t have the same appreciation for code quality as those with unit testing background. The SET keeps the code in check. Unlike classic eXtreme programming where there’s a fully collective code ownership, in this way the SWE is responsible for the code he writes, but the SET is responsible for making sure code quality is up to par. With this hybrid approach it would really take a double disaster for things to go terribly wrong, and in that case you just keep writing unit tests until you’re back on track.
0 Comments

Your comment will be posted after it is approved.


Leave a Reply.

    ​Author

    Picture
    The posts on this site are written and maintained by Jim Lynch. About Jim...
    Picture
    Follow @JimLynchCodes
    Follow @JimLynchCodes

    Categories

    All
    Actionscript 3
    Angular
    AngularJS
    Automated Testing
    AWS Lambda
    Behavior Driven Development
    Blockchain
    Blogging
    Business Building
    C#
    C / C++
    ClojureScript / Clojure
    Coding
    Community Service
    CS Philosophy
    Css / Scss
    Dev Ops
    Firebase
    Fitness
    Flash
    Front End
    Functional Programming
    Git
    Go Lang
    Haskell
    Illustrations
    Investing
    Java
    Javascript
    Lean
    Life
    Linux
    Logic Pro
    Music
    Node.js
    Planning
    Productivity
    Professionalism
    Python
    React
    Redux / Ngrx
    Refactoring
    Reusable Components
    Rust
    Security
    Serverless
    Shell Scripting
    Swift
    Test Driven Development
    Things
    TypeScript
    Useful Sites
    Useful Tools
    Video
    Website Development
    WebStorm
    Writing

    Archives

    March 2023
    August 2021
    February 2021
    January 2021
    October 2020
    September 2020
    May 2020
    April 2020
    February 2020
    January 2020
    December 2019
    October 2019
    September 2019
    August 2019
    July 2019
    June 2019
    May 2019
    April 2019
    March 2019
    February 2019
    January 2019
    December 2018
    November 2018
    October 2018
    September 2018
    August 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    January 2018
    December 2017
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    May 2017
    April 2017
    March 2017
    February 2017
    January 2017
    December 2016
    November 2016
    October 2016
    September 2016
    August 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015

    RSS Feed

  • Blog
  • About Jim
JimLynchCodes © 2023