Course code: WEB-10
Years with company:
Less than 1
Primary programming language:
Other programming languages:
C++, C#, Python, Ruby, Shell Scripting
Unit test harnesses:
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.
Various embedded platforms -- from embedded linux down to tiny bare metal microcontrollers depending on the application.
Various - Yocto, Keil, various IDE's provided by chip vendors, various debuggers, etc. Like the target systems -- it depends on the application.
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.
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.
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.
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.'