Course code:
WEB-10
Years with company:
Less than 1
Years programming:
15+
Primary programming language:
C
Other programming languages:
C++, C#, Python, Ruby, Shell Scripting
Unit test harnesses:
Ceedling, Nose
Something else:
I came from a safety critical background out of school, and since testing was required with independance -- software engineers were dissuaded from spending alot of time testing. I have railed against this throughout, as I feel that the benefits to the developer far outweigh the cost. I am suprised that this feeling is not more prevalent in embedded developers that I talk to, but I wonder if it isn't more of an issue of experience and introduction.
Test practice now:
Unit tests, manual integration tests, a system test group.
Target system:
Various embedded platforms -- from embedded linux down to tiny bare metal microcontrollers depending on the application.
Dev tools:
Various - Yocto, Keil, various IDE's provided by chip vendors, various debuggers, etc. Like the target systems -- it depends on the application.
Build time:
31-60 seconds
Coding standard:
Defined and released in our SCM system. Pretty vanilla -- seems to have some parentage from automotive systems (fair amount of MISRA like stuff). Most of the standard is more shoulds than shalls, however, and I haven't seen much review against it.
Function too long:
At my current company -- no hard and fast rules. I think the code standard provides some weasel wordy style guidance. My personal rule is if it isn't clearly focused on a single 'job' and is trying to do too much -- refactor it.
Code reviews:
Using a Github style code review during the pull request. Currently no checklists / requirements on the code review. Seem to be taken seriously and done well. Much more focused on functionality than boilerplate.
Code time:
60
Test time:
20
Debug time:
20
Favorite thing about dev:
I love making things and solving problems, and software is about the most direct analogy to this that I know of. Software is awesome because you can make anything you can imagine -- which is SO COOL.
Least favorite thing about dev:
Blind hatred or love of 'agile/scrum' while simultaneously misunderstanding it. Monolithic schedules that change all the time. Not wanting to invest to get more efficient or use new tools.
Tdd knowledge:
I've read most of your book along with other blog posts / online resources. I've been playing with some of the ideas this last 6 months, but not formally as TDD -- more just testing things with automated test.
Why are you attending:
TDD and unit test applied to embedded systems -- especially mocking and faking. I need more ammunition to convince the organization that 'if we did things a little differently, we could have much better software for not much additional cost.'