| 0 |
15 |
C/C++/C# |
C#, Python |
Google Test
Unity
NUnit |
I have been doing embedded and application level development in industry for 10 years. |
Integration and Functional/System Tests. |
stm32F429 with motors, pumps, and various peripherals. |
Keil MDK
Segger JLink
VS Code |
1-5 minutes |
MISRA C99, C++11. |
Violates SRP and I have to scroll down too long. |
We are developing software development workflows which are now including Code Reviews with associated Git Pull Requests. |
4 |
2 |
4 |
The persistent challenge and seeing how software can control devices. |
Bugs and defects. The challenge and communicating the challenges to others. |
Test-driven development. The tests drive the implementation.
1. Write a failing test
2. Add implementation
3. Re-test
4. Refactor
5. Retest
6. Continue cycle until "all" the tests are covered. |
When working in application development (C# .NET) unit/integration testing was integral to software development workflows. I would like to bring that into my current role of developing embedded development. |
Show
|
| 18 |
25 |
C++ |
Python, Java, C#, APL, ... |
CppUTest, xunit variations for C/C++, Boost Test, etc. |
Think of myself as programmer of scientific instrumentation. (20 years) More of an Agile/Scrum trainer these days, wanting to get back to more programming again. Want to apply it to eco sustainability challenges.
|
Personal projects: largely TDD
Professional projects: a bit of TDD |
Current: Multi Arduinos used on a NASA project for photovoltaic R&D, to improve power output for the Lunar Gateway project. Simulated sun system for testing PV's on earth, plus balloons to 120,000 ft to calibrate things in space. |
Eclipse, Arduino IDE, |
11-30 seconds |
By discussion of three main people involved |
Lack conceptual. Duplication. Hard to test. |
Rare. Usually when there are questions. Or at end of completion of a new feature area. |
30 |
30 |
40 |
Creativity. Impact via important work. Fast feedback. |
Debugging. Hurriedly trying to learn necessary new things. Setting up complex toolchains before making simple progress. |
Many uses over the last 20 years. (simple level) Received training. Done training. Paired. Paired with Ward a number of times. Created a few simple test frameworks when one wasn't found. (Old Matlab, Basic) Made a variety of simple C/C++ frameworks. |
Increase fluency. What to get better at making rapid TDD progress in legacy codebases. Less late nights and weekends getting a framework in place... |
Show
|
| 6 |
30 |
C/C++ |
Ada, Java, C#, VB, Python |
CUnit |
Former Naval Officer, 23 years in software industry |
unit test, integration test |
Embedded |
Visual Code |
1-5 minutes |
No formal coding standard |
Try to do too much in a function |
Thorough code reviews |
50 |
35 |
15 |
Enjoy the puzzle-solving aspect, enjoy being in the lab and running the code on the hardware |
documentation |
light tangential experience, want to learn a lot more about it! |
Interested in learning more about TDD |
Show
|
| 2 |
15 |
C |
C++ |
None |
Taking a risk-based approach to developing device software reminds me of previous experience mountaineering. I also find that association amusing. |
Our testing is done manually. Manually writing test cases for functions and modules. |
Arm Cortex-M4, mainly STM32F4s |
Keil uVision MDK, Parasoft C/C++ Test |
30-60 minutes |
Currently undefined for the organization. Trying to st |
When I need to scroll up or down to find relevant portions of information within the function, it's cause for me to reconsider if anything done in the function is needs to be moved into its own function. |
Reviews are done during pull requests of our git-based repository. |
30 |
40 |
30 |
When approached properly, developing software can be intentional and deliberate to produce amazing things the world has never seen before. |
The misconception by other groups in multifunctional teams that developing software is quick and easy.
It is quite easy to walk down the wrong path and write software quickly and haphazardly to produce code that functions for only "right now". |
I know that it relies to requirements as its pillars and testing against these requirements to consistently produce functional and purposeful code. |
In previous organizations I've worked, there wasn't a focus on testing. My co-worker shared 'Test-Driven Development for Embedded C' when he joined the org and I ended up purchasing a copy. After found this training while looking for more resources. |
Show
|
| 5 |
~10 |
C, C++ |
Ruby
Python
Rust
|
Check - C
CUnit - C
CxxTest - C++
Boost::UnitTest - C++
Rust - built in to the language!
Isn't just having your Python/Ruby script run without exception enough of a test?
|
I really enjoy music - both listening and recording. Since I also like writing programs for embedded systems, I have written a program for a Raspberry Pi that will rate the quality of a vinyl record on a scale of 1-10.
I sometimes enjoy writing python scripts that generate music that only a computer could reproduce, but the music generated is never good. |
C production code is tested using CUnit. We chose this library because it was very easy to compile with our custom toolchain and does not require an OS.
C++ production code is tested with CxxTest. We chose this library because the python script that auto generates the test harness is easy to configure for use without an OS.
All unit tests are run on the target system. This allows us to unit test things like GPIO assertions and interrupt handlers. |
SoC with a custom MIPS processor. |
Custom C and C++ compiler and toolchain (gcc patch).
CMake for defining the build rules, which generate Makefiles we use for building.
CUnit for C unit testing.
CxxTest for C++ unit testing.
Emacs |
1-5 minutes |
We don't really have a coding standard. We use CodeSonar as a static source code analyzer/linter/good practices checker. |
If it can be made shorter and clearer. If it would be better split up into two or more separate functions. If it is a reroll of std::find. If it is a reroll of std::accumulate. If it is a reroll of std::transform or std::for_each. |
Usually involve 4-6 reviewers, each reviewer spends 2 weeks annotating the code. We use a custom tool that allows reviewers to collaborate and make in-line annotations without modifying the code. |
50% |
40% |
10% |
Software is really about automating things. It's about spending x amount of time today to save yourself and others 10x amount of time or more in the future. My favorite thing about software is the feeling of time saved. |
I'm not convinced documentation is as important as everyone says it is. When there's too much, there's a sense of ease but you often miss the important parts. When there's not enough, there's a sense of panic but you can always elaborate more. |
*Write tests before you write code.
*Unit testing should be able to hit ~100% code coverage.
*Tests should follow the setup, act, assert pattern.
*Unit tests should never depend on test ordering.
*Test feedback should be immediate and readable. |
I'm interested in TDD, and especially interested in bringing it to embedded systems programmers. I've used it in my projects, and have had success bringing it to my group, but I want something to be a success story for TDD in other projects. |
Show
|
| 5 |
4 |
C |
python |
unity
cpputest |
I love to learn, I'm always reading to improve my practice |
unity test harness running on simulator,
manual with debugger |
Microchip dsPIC33, ST stm32f4, multiprocessor safety-critical system |
MPLAB X, Keil uVision, Visual Studio Code, batch files |
11-30 seconds |
Existing but not really enforced |
when it accomplishes more than 1 logical function |
Not optimal |
33 |
33 |
33 |
bending matter to my will, muahahaha |
no universal rules and good practices |
attended EOC2021 workshop,
currently reading James book,
just finished a project test-driving it |
I want to make better software, faster.
I want to spend less time doing manual testing. |
Show
|
| 0 |
15 |
ASM |
C, C++ |
None |
I was educated as an electrical engineer and learned programming along the way as a necessity. |
Testing the end product directly, with a human. |
Various avionics systems, some of which are ARM microcontrollers, and some which are x86 embedded linux systems. |
VSCode, Various IDEs for different microcontrollers, svn, git |
5-30 minutes |
Match style that already exists, be self documenting, dont leak memory |
Functions should only do one logical thing. |
Using crucible currently, but not very experienced with it |
50 |
20 |
30 |
Being able to develop software lets me create just about anything imaginable. |
Remembering syntax for languages I don't use very often. Fighting with different IDEs and Debuggers. |
Very little, this is the first job where I have encountered tdd. |
Required training for my position. |
Show
|
| 17 |
10 |
Java |
C/C++ |
None |
I have spent the last 17 years working as a Sales Engineer where my programming duties were 1/4 of my workload mostly centered around developing SW to automate testing of HW, creating demo/POC applications to reveal ROI of business use cases for HW/SW solutions, and creating demos for development teams. Recently I accepted a position with Engineering as a full-time Firmware/Software Engineer, this recent move will allow me to build upon the basic programming experiences that I have had to date. So some concepts of this course will be new to me and I am eager to jump in and learn. I have a BS in Computer/Science and Engineering. |
I generate a test plan independent of the SW project based on user requirements/use-cases and then manually create a test document to run the SW through the tests |
x86/ARM |
Visual Studio, Eclipse, Android Studio |
1-5 minutes |
I try to write code in a way that is easy to understand avoiding additional complexity when it is not needed for efficiencies and also making use of models/patterns. Also, I tend to test frequently to keep debugging complexity low. |
When the scope of the function grows to large |
In my prior position as a Sales Engineer I lacked access to really experienced mentors for code reviews. I'm hoping to get a lot of feedback from code reviews in my new role in Engineering. |
60% |
30% |
10% |
I enjoy the constant state of learning, the opportunities for creativity, and the complex problem solving opportunities. |
When feature creeping gets out of hand |
Not much |
I am a new hire in the Engineering organization and eager to start learning and adapting to including these important concepts in the projects that I get to participate in. |
Show
|
| 0.5 |
4 |
C++ |
C#,C,Java,JS,Python,Perl |
Boost Test Framework in school |
I was in web development using C# and JS for 2 years before moving to embedded systems development |
Test using the product and multiple different inputs to see if I get the desired result. |
Zebra mobile printers running on c/c++ |
QNX Momentics |
1-5 minutes |
I always try to keep things as simple as possible and reuse code that has already been tested in other areas of the application. |
A function should really only complete one task, so if a function is doing too much it should probably be broken up. |
I call another developer that is an SME in that area and show them my changes. They ask me to change something or give their approval then and there. |
20 |
40 |
40 |
The feeling of solving what feels like a difficult problem and creating something that can help a customer. |
How long it can take to find bugs sometimes |
I haven't heard of it, so just what I can gather from the name. |
My boss signed me up, but I am excited to gain a new skill and learn something new. |
Show
|
| 18 |
21 |
C |
XML |
cmocka, Valgrind |
I studied electrical engineering and worked as a hardware developer for 7 years before starting software development. |
The most important are functional developer tests. Automated testing is carried out in development with cmocka.
Our system test writes much more extensive automated tests, mostly in Python. |
Our target systems are 2G / 3G / 4G radio modules. |
Qualcomm Build Environment, Qualcomm tools like QPST, QXDM and many more. |
5-30 minutes |
- |
When it becomes confusing and difficult to maintain. |
Are done together with colleagues. |
25% |
25% |
25% |
You can work in a logically structured way. |
That one renounces quality for reasons of cost. |
TDD, perhaps in a different form, we had many years ago. The idea was: you write the tests first and then develop. That didn't work. |
This training was assigned to me by my boss. |
Show
|
| 20 |
37 |
C |
awk, assembler, some more here and there |
? |
I really know what a stackpointer is and what an interrupt is. |
In most cases: pepper with Debugs, run & check, remove debugs |
Embedded multicore systems |
editor, compiler, debugger |
5-30 minutes |
Avoid unnecessary lines, so that a loop fits to one screen page |
I don't know |
In most cases I am involved in advance and know the changes. |
50 |
25 |
25 |
Freedom & creativity.
Understanding & changing code I have not written by myself.
|
Limitations by advice / tools. |
I think I know what it is about |
On advice |
Show
|
| 20 |
40 |
C |
python |
cmocka |
My programming focus is on hardware related stuff of embedded systems, mainly audio. |
1) compiler as static code analyzer
2) cpp check as static code analyzer
3) source code review
4) manual tests
5) cmocka on a daily base via jenkins
6) system test cases on a daily base via jenkins |
Embedded system with multiple cores, typically based on ARM 32/64 bit. |
Source Insight
Beyond Compare
CPP Check |
5-30 minutes |
Full awareness that the person who will maintain my code might be a manic serial killer who knows where I live.
Never change the coding style of an existing file. |
If comments are needed which are not related to a single line. |
Very useful.
The skill is to invite people which are able to give useful feedback. |
20 |
60 |
20 |
It is creative. |
If time or money are wasted for any reason. |
The idea is quite obvious. It is not the only but maybe the best way to get meaningful unit test cases.
I would rate this a helpful if code is under your control. It is difficult to apply if only minor changes are added to a suppliers code. |
I get the chance to do this. Being a senior engineer team members ask me each day for help. If I am not trained I cannot tell what is useful and what is not useful.
It is not the question whether it makes sense.
I am convinced that it make cents :) |
Show
|
| 20 |
40 |
C |
C#, CPP, Assembler |
Jenkins CI |
? |
Jenkins CI
Debugger
Logging |
Embedded ARM |
Some |
5-30 minutes |
yes |
Need to scroll |
Gitlab |
? |
? |
? |
? |
? |
? |
Company training plan |
Show
|
| 22 |
40 |
C/C++ |
VBScript, Powershell, Java, Perl. |
None |
I'm the only one within my software department who doesn't work at the software inside our products. Instead I'm responsible for more or less everything else. These are of course external drivers to access our products but also factoring tools, test tools, adminstration tools etc.. |
Testsuites provided by OS manufacturer (Windows kernel drivers), self written test suites (Android and Linux drivers), manually (everything). |
X86 systems with Windows or Linux, Android systems. No embedded systems! |
Many, depends on the kind and target of my current task. |
1-5 minutes |
? |
If it doesn't fit to the screen in a whole, although that sometimes cannot be avoided. |
? |
50 |
25 |
25 |
It is well paid. |
It could be paid better. |
It must be something between undriven and panic driven development. |
I have no choice. |
Show
|
| 21 |
~25 |
C/C++ |
python, shell
if necessary: java, perl |
propriatery ones, sharness, python unitest |
I am doing a survey right now :) |
cmocka (job), by using it (private) |
in general: embedded platforms
in detail: embedded C or Linux based |
linux and google |
Under 10 seconds |
still trying to find one that I like so much that I follow it without thinking about it. |
if I had to press 2 times page-up because I forgot what happend before. |
I try to take them serious. if I can't read it like a book or simply do not understand something, I complain. |
3 |
3 |
1 |
I can automate stuff that I do not like to do again and again and again or solve issues where computers are simply faster than humans |
so many bad code, so many new hypes. |
it stands for "T_est D_riven D_evelopment" and if really done then it can help to make someone think before starting to code |
1. boss told me so
2. see the chance that I can learn something or get some new ideas |
Show
|
| 21 |
21 |
C |
- |
for GCf tests: R&S test equipment,
for LwM2M: our LwM2m client on our device connected to our test server,
dedicated tests are performed by out test team |
protocol stack developmnet for cellular technologies 2G-4G, e-CAll development, LwM2M |
directly in client - server scenarios |
- |
- |
5-30 minutes |
- |
if it doesn't fit to one screen ;-) |
- |
50% |
30% |
20% |
- |
- |
Nothing, this topic is new for me. |
- |
Show
|
| 0 |
10 |
Rust |
C, C++, Python |
Cargo, CMake (ctest), gtest, gmock |
I also work on open source Rust crates |
I typically add unit and integration tests when I am working on something that could have runtime errors that could result from my code, like parsers, algorithms, etc. In Rust I often avoid writing tests by using the type system to make certain error cases impossible. |
I typically develop on Ubuntu, but I recently got a Mac with Apple Silicon, and I also use Windows. Basically, everything. |
I typically use VS Code + Rust Analyzer + Cargo. |
11-30 seconds |
I like to see the open source ecosystem reused where appropriate and contributions upstream rather than internal forks. |
If it is hard to read because the comments and code aren't sufficiently high-level to make reading easy then it should be split to improve code readability. |
We often develop in a mob, allowing for live code review. |
80 |
15 |
5 |
If we develop reusable, clean, and maintainable software, it can be evergreen and build upon the existing work of others to get us to a higher level of coding abstraction. |
I don't like when coding is performed without a plan for the overall architecture and code reuse. |
I am familiar with the process of writing tests in advance and making incremental changes to avoid getting ahead of yourself. I only do it when I am trying to implement something that is non-trivial. |
For work and to learn =) |
Show
|
| Half Year |
6 |
Python |
C, C++ |
Pytest |
I'm a relatively junior engineer and am interested in learning how to develop software more efficiently and cleanly. |
Using some flavor of test driven development. |
No specific system in mind, usually application-specific. |
Primarily VS Code and everything that comes with it. |
1-5 minutes |
Coding standard is relatively ad-hoc. Tends to depend on the situation and the project I'm adapting to working on. |
When it does more than the functions purpose. |
Currently depends on the project, but generally pretty high-level. |
60 |
20 |
20 |
There are endless ways to approach many problems, there's satisfaction in doing it well. |
It isn't all exciting- keeping up on new standards and methodologies can be hard to do. |
Nothing officially, just a general understanding of the design methodology from some books. Basically that you structure your developed code around pre-written tests. |
I've used TDD before, but I wanted to get a real understanding of what that means to become a better developer. |
Show
|
| 4.5 |
15 |
C |
C++ |
utest, gtest |
i work in Ypsomed in the product development department. we are developing a insulin patch pump. i currently do not implement software anymore, as i have taken the role of the PO for the embedded SW. |
gtest unit tests |
Cortex M4 dual controller system with BLE |
my collegues can answer this better than i could. |
31-60 seconds |
own coding rules, heavily based on MISRA |
when it is hard to understand and maintain. |
my collegues can answer this better than i could. |
20 |
20 |
20 |
creating behaviour for a product and creating value out of that. |
running out of time and deliver unfinished (incomplete and buggy) SW to the customer |
i have started reading your book and we had discussions inside our company about it. but havent worked according to it so far. |
i think that i previously have worked a little bit like this: adding a litte functionility => testing => adding a little more functionality.
it would be great to work according to a "professional" method, to get better |
Show
|
| 4.5 |
15 |
C |
C++ |
utest, gtest |
i work in Ypsomed in the product development department. we are developing a insulin patch pump. i currently do not implement software anymore, as i have taken the role of the PO for the embedded SW. |
gtest unit tests |
Cortex M4 dual controller system with BLE |
my collegues can answer this better than i could. |
31-60 seconds |
own coding rules, heavily based on MISRA |
when it is hard to understand and maintain. |
my collegues can answer this better than i could. |
20 |
20 |
20 |
creating behaviour for a product and creating value out of that. |
running out of time and deliver unfinished (incomplete and buggy) SW to the customer |
i have started reading your book and we had discussions inside our company about it. but havent worked according to it so far. |
i think that i previously have worked a little bit like this: adding a litte functionility => testing => adding a little more functionality.
it would be great to work according to a "professional" method, to get better |
Show
|
| 2 |
5 |
C |
C++ and VHDL |
CppUtest |
I have started my career as a Hardware developer and decided to change to Embedded Linux device driver developer. After a year, I started to work with SoC (VHDL + Embedded Linux + C programming), where I spent 2 years.
Nowadays I work mainly with C for embedded environments. |
For newly created software units, unit tests are applied during development ( first the logic is implemented, then tested).
For legacy code, tests are done by looking at the integration level. |
Low power Microcontroller 32-bits. |
Eclipse, IAR , Visual studio, azdo, EA. It depends on the project. |
1-5 minutes |
We use Misra C standard and additional company-specific code guidelines |
When a function starts to have more than one scope and logic.
Rule of thumb, around 50 lines of code. |
Done via Pull request |
20 |
50 |
30 |
The ability to create value by translating human needs into lines of code, that can be easily maintainable, scalable and flexible so that new needs can be effortlessly added to the existing solution. |
Nothing comes to my mind now. |
Improve software maintenance and flexibility |
I am very interested in the TDD approaches, but I am still not sure about the limitation and challenges of this approach. |
Show
|
| 2 |
14 |
C |
C++ |
CppUTest, GTest |
I like collaboration instead internal competition |
unit-tests, integration-tests |
medical embedded devices |
VS-Code, Docker, gcc (cross compiler), gdb debugger, git, microsoft azure for change management and continuous integration |
11-30 seconds |
MISRA 2012, using internal coding guidelines |
when the body of the function could be easily split based on the separation of concerns principle or when the function is not easily unit-testable |
one reviewer, using pull-request workflow |
50 |
30 |
20 |
clean design, modularized, automatic testing for continuous integration |
reverse engineering spagetti code; long feedback loops for (test) results |
the philosophy of writing first the test cases before the implementation and having the corresponding tests for the implementation which locks a module functional behaviour, making then easier to change without being afraid of introducing regressions |
I want to have a proper reference of what TDD means and which news and advantages brings, including the practices on what is the best way to apply the TDD theory. |
Show
|
| 0.5 |
3 |
C |
C++
Rust
Python
Javascript |
I don't think I've used one? I've written test *benches* with test vectors for SystemVerilog before, but that might not be the same. |
I have a lovely Bengal cat who occasionally uses my legs as his scratching posts and my arms as his chew toys. |
Currently, either Cucumber or just running the code against CI when I push to Git. |
Small evaluation board from ST fitted with a custom display |
Visual Studio Code
STM32CubeIDE |
31-60 seconds |
- Red, green, refactor
(I'm not entirely sure what else this entails) |
If I forgot what I wrote earlier... |
We do mob programming, so we don't *usually* do code reviews as everyone is generally in the loop.
Sometimes when we have to do solo work, though, we'll pull 1-2 people in to ensure the code is sane. |
15 |
15 |
70 |
I like living in the embedded layer of coding, where it directly influences hardware. It's nice to see changes in software map to changes in real life. |
Debugging. Sure, I might be the same as the majority (as stated in the intro video), but, yeah, the abyss of debugging can sometimes be a little deep. |
Write the test first, watch it fail (red), make it pass (green), and then improve it (refactor).
Start from the simplest possible tests.
Make it pass in the most direct way. |
Mandatory by the company.
I'm also personally invested as TDD is a standard we've been using and I'd like official training on it to improve my understanding. |
Show
|
| 1 |
40 |
f# |
c#; rust; |
fsunit; sunit; nunit; xunit; junit; cucumber jvm; cucumber ruby; cucumber rust; fitnesse with smalltalk fixtures |
got into tdd (desktop, smalltalk) 20003 and it breathed new life into my career; ten years ago worked on an eXtreme programming team on smalltalk and c++ embedded linux, first exposure to TDD embedded linux. We used fitnesses. This is my first TDD bare metal time. Enjoying rust. Left C/C++ in the rear view mirror a decade ago, hoping I can pivot back to them in class, or pair in or use rust. |
ideally most of my day -- above 80% -- spent in the happy place of the red-green-refactor micro loop. 3 months into job here, about 5% in that place, 95% in what Geepaw calls GAK activity, others, yak shaving. |
bare metal rust some kind of STM processor (new to this space I am) |
rust; c++ for the legacy bits; applying strangler pattern to eliminate that, in hopes of 100% rust 0% C++ |
Under 10 seconds |
I apply Beck's 4 definition of done (passes test? reveals intent? no duplication? fewest elements?) |
I come from cultures (Smalltal, F#, Lisp) where a ten liner is a long one. |
we mob - reiews are real time; asynchronous review (I'm looking at you, Git PR) are for those sad souls who default to solo. |
10 |
45 |
45 |
getting paid to think; and pairing in to think together? joy squared. |
bugs - best tester in world taught me to call them mistakes |
I've been coaching whatever team I'm on in it the past decade, but I am still learning. Recently F# way -- and to an extent Rust -- lean on compiler: can my compiler be my unit test? Can I write code in such a way if it compiles it probably works? |
I want to learn TDD in embedded rust; I've a hunch the principles are the same (decouple I/O from branching logic) but, looking at our code base, shake my head: why are we so dependent on hardware for every little thing? What am I missing? |
Show
|
| 0 |
20 |
C/C++ |
Python, Rust, Assembly |
Catch, Rust unit tests |
Experienced Embedded Software Engineer, Technology Translator and Woodworker Wannabe |
unit tests, integration tests, regression tests |
ARM Cortex M |
VSCode/Vim, GDB, STLink, Rust/C++ |
1-5 minutes |
C++: currently none
Rust: all enforced by Rust Clippy and Fmt |
cannot fit my (27" portrait) screen... |
done by Mob/Pair Programming |
3 |
4 |
3 |
Create new things; solve difficult problems; eliminate duplication/repetition |
repetition of implementation and bugs/errors |
think/write test before think/write code
create a failing test first
only implement enough code to pass the currently failing test |
i am still a newbie in TDD. would like to learn more |
Show
|
| 2 |
20 |
C/C++ |
some python, little bit of lua and javascript. |
google test, cppunit, cmocka |
university degree in computer science ~15 years ago. embedded software engineer in medical and space business. |
Using google-test. Write code, then test.
Target is 100% coverage, for application logic down to device drivers. |
Embedded ARM device |
CLion
VS-Code
docker
clang, iar,
git
gitlab
|
31-60 seconds |
there is no defined standard. |
when it does not fit on the screen (maybe 40 lines of code). I know there is room to improve ;) |
we do a code-review per pull-request. review is done by second person, a pull-request holds code from 3-5 days of work. |
40 |
30 |
30 |
You never "know" it.
There's always something new to learn. Building bigger things out of small blocks.
|
debugging ;).
badly formatted code (different styles from different authors in single file), actually non-tool-formatted code.
writing documentation.
project managers that trade (initial) development time for quality. |
for each new "thing":
write test first. then write code to pass all tests. cleanup.
|
Got an invitation from my contractor. Remembered your name from the book I bought maybe 5-6 years ago. wanted to attend. |
Show
|
| 0 |
8 |
C |
Python, C++, C# |
Tessy, Parasoft, GTest, VS Native Unit Test |
I have worked before starting at Ypsomed as a working student at a Cyber Security Department. Where I have been working on the generation of generic IDS rules.
I am working as a DevOps Engineer at Ypsomed. |
As a DevOps engineer I mostly write scripts, and then by executing the script, I would see, wether the script works as expected or not.
(In my side projects I use gtest and the Visual Studio native unit test framework, and the debugger) |
n/a |
GitHub, Docker, Azure |
1-2 hours |
n/a |
Deeply nested control structures and when you cannot determine the purpose of the function in a reasonable time |
Done through pair coding and at the pull requests |
50 |
30 |
20 |
Complex challenge |
Finding errors/bugs |
The idea behind it is clear, but I have never used this approach before. |
There was a single free slot, and it is a class, where I can learn a lot. I have been working at Siemens also on the automatisation of the debugger and had to use code coverage to generate IDS rules, but TDD is new to me. |
Show
|
| 16 |
20 |
C++ |
Python
Infrequent: java, c#, ruby, javascript, ... |
Many including CppUTest googletest, boost, assert, unittest.py junit, nUnit, custom, ... |
I like the challenge of getting unit tests working in legacy code. I'm humbled that more programmers don't currently do TDD. |
Combination of class-level unit tests, automated integration tests and system tests, plus manual exploratory manual testing. |
Arduino, embedded linux, embedded Windows, desktop exercises. |
Mix: Macbook, Eclipse, AtmelStudio, Aduino IDE, TextMate, Visual Studio |
31-60 seconds |
varies by project. Usually minimally specified and syntax vs semantics/design. Rarely "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" by Herb Sutter et al |
When it's hard to quickly understand or could be clearer if refactored. Could be as little as a one-line wrapper with a good intent-revealing name. Probably no bigger than one screen full. |
varies by project, from zero to by weekly to pairing |
10 |
40 |
50 |
Quick tangible progress. Quick feedback. What software enables in the world. |
Feeling on not fully understanding things. Risk of small mistakes having big consequences. The common perception that programmers are already doing the best they can using limited approaches. |
I've studied and practice TDD. I use it on my projects. I use it on client projects when possible. It's common that I'll demo some examples in a code base but that the teams will not take it and run. Reasons cited include: no time, too hard, fragile. |
To grow more fluency with TDD for embedded. To grow techniques. To learn ways to explain and motivate the use of TDD. |
Show
|
| 0 |
0 |
python |
shell script |
0 |
Started my career in SW industry as QA (4) then did MS and CS and worked as technical support engineer for a couple of years. R&D application engineer for last 6 years where I was using little bit of shell scripting while working on linux platform for network adapters. Role at GF is of verification engineer and where I have to automate tests using python and need to do database integration and use Github for CI-CD. |
|
|
VS code |
4-8 hours |
|
|
|
8 |
5 |
7 |
It helps to automate which helps with an accuracy of test readings and less human error chances. |
|
My understanding is that first we need to write the testcases based on the feature requirements and then in order to pass that testcase we need to write the code. |
I am a software verification engineer and I hoping that TDD will be beneficial for me from testing and automating tests point of view. |
Show
|
| 5 |
5 |
C++ |
C Sharp, Python, Java |
Karma, Jasmine |
I like technology but i really enjoy unplugging |
Writing unit tests for existing code |
Uses java script and python |
VS Code |
5-30 minutes |
Depends on which language is being used |
When it has too much functionality |
They go through peer review processes |
33 |
33 |
33 |
Seeing the results that the code creates |
Sometimes hunting bugs can be tedious |
I know it can save time in the long run |
We were just doing unit testing for my project and I struggled with writing them |
Show
|
| 6 |
9 |
C# |
C++, Javascript |
na |
Im into paleontology |
Test in development environment, code review, test on target platform, then whole system integration testing. |
Laptop running Windows 10 |
Visual Studio, git, VMWare |
Under 10 seconds |
Varies per project |
When it does more than one thing |
Peers review code individually and provide feedback prior to an online meeting where we review the code, what its supposed to do, and what it actually does |
60 |
20 |
20 |
Problem solving |
Sometimes simple things take a lot longer than they should |
Nothing |
Developer testing is very ad hoc and I'd like better methods |
Show
|
| 1 |
30 years |
C Sharp |
None |
NUnit
TypeMock / NMock |
I have been in the SW industry for over 30 years. Mainly working on embedded systems in regulated environments. Most recently I was Head of R & D at Conduent CH, makers of Fare Collection Systems.
My coding experience start in C++, then moved to Jave and then to C#.
Most of my work over the past 10 years has focused on leading teams and driving organisations towards agility. I am a certified in SAFe, LeSS, Scrum.
Currently at Ypsomed I lead a team of Embedded Software Engineers but most of my time is working as an Agile coach supporting the Agile Transformation.
|
We are using Google Test / Google Moack for Unit testing and we have own frameworks for end to end testing.
TDD is encouraged but not implemented correctly in the company. |
STM32 |
The team can provide information |
5-30 minutes |
The team can provide info |
When it is performing multiple activities and cannot be shown on one screen |
We use the four eyes principles and all code is checked before being committed. We have recently moved to using Git Pull requests for all activities (last week ) |
40 |
30 |
20 |
Writing some code and getting some reaction in the hardware, be it a simple light operating or reading in data. This gives me a thrill |
Documentation |
Read all the books, know the principles and how to do it in C#, Scrum teams
Know it needs a mind set change to realize it correctly.
Know it is not about writing tests in parallel to coding :-) |
I want to move my team to use TDD correctly and to address some of the inherent difficulties to use the concept in C Embedded environments.
Need the suppor tof an expert |
Show
|
| 8 |
30 |
C |
- C++
- C# |
- Visual Studio Unit Test
- Googletest |
55 years old / married / 2 children / electrical engineer / SW for telecommunication, automation, ATM, medical technology in the past / like reading and cooking / will become a ypsomed team member beginning of next month |
- Manually on the target according test reports |
New development of a laser system for eye surgery - responsible for the FW in distributed system (Win10 (GUI); Linux (System controller); 7 x FW w/o OS). Subsystems with FW connected as slaves over USB to the System controller |
- STM32CubeIDE
- Enterprise Architect (UML/SysML) |
11-30 seconds |
"Copy-Paste" with some minor adaptions from Embedded C Coding Standard by Michael Barr (https://barrgroup.com). |
If the function contains many different functional aspects. E.g. reading file > processing input data > writing data. |
Only if searching a bug or if listed as a step in test report. No formal procedure defined. |
70 |
10 |
20 |
With very few effort you can dramatically change the behaviour of a whole system. |
Because you can dramatically change the behaviour of a whole system with very few effort, everybody thinks everything can be fixed by changing the FW |
Some internet researches about the basics. Test case first followed by implementing the functionality |
Training organized by my new boss for his whole team. |
Show
|
| 0 |
8 |
C |
Python, C++, C# |
Tessy, Parasoft |
I have worked before starting at Ypsomed as a working student at the Cyber Security Department at Siemens. Where I have been working on the generation of generic IDS rules.
I am working as a DevOps Engineer at Ypsomed. |
As a DevOps engineer I mostly write scripts, and then by executing the script, I would see, wether the script works as expected or not.
(In my side projects I use gtest and the Visual Studio native unit test framework, and the debugger) |
n/a |
GitHub, Docker, Azure |
1-2 hours |
MISRAC2012 |
Deeply nested control structures and when you cannot determine the purpose of the function in a reasonable time |
Done through pair coding and at the pull requests |
50 |
30 |
20 |
Complex challenge |
Finding errors/bugs |
The idea behind it is clear, but I have never used this approach before. |
There was a single free slot, and it is a class, where I can learn a lot. I have been working at Siemens also on the automatisation of the debugger and had to use code coverage to generate IDS rules, but TDD is new to me. |
Show
|
| 2 |
1 1/2 |
Python |
LabVIEW, C++ |
PyTest, UnitTest |
I am an Electrical Engineering graduate who shifted into Verification work and enjoys it more than what came before it. Programming was once a dreaded thing to practice but has become one of my favorite things to do. |
PyTest, UnitTest, other test API, and trial and error |
I am currently developing test software using a Windows 10 Lenovo x64 machine, but plan to create tests to be deployed and triggered on Raspberry Pi 4's for actual CDCI. |
Visual Studio Code IDE, Thonny IDE (for Pi Pico or lightweight Pi 4 work), GitHub Actions |
1-5 minutes |
I am usually writing interface code for equipment that's later tested so a standard is that regardless of the protocol being used on the equipment, we name our functions similarly. By doing this we basically know all functions for all equipment. |
When it does more than one thing towards the target. |
I do not have code reviews as a Verification Technician. |
40 |
40 |
20 |
Being able to create something very specific for an custom application. Later being able to modify my programs and reuse them for an entirely different application but slowly building a collection of personal libraries that make my job easier. |
Packaging, setting up environments, and troubleshooting something to later realize the problem was somewhere else. |
Off the top of my head, I understand it to be the practice of consistently testing every other line of code you write assuming everything is a modular piece. |
R&D Director (at the time, he is no longer with us), encouraged that the Verification Team attend along side the the Development Team due to how valuable it could be for overall progress made. |
Show
|
| 30 |
10 |
c/c++ |
Java, Swift, Ada, SQL |
none |
Play Chess? |
yes |
embedded platforms |
Tornado 2.2 |
31-60 seconds |
C\C++ |
do not know this |
peer |
33 |
33 |
33 |
create capability |
the lack of documentation |
This is my first instruction in Test-Driven Development |
To learn about TDD and how it can be applied to automated testing. |
Show
|
| 2 |
7 |
C |
C++ only for unit testing |
Google Test |
30 years old Swiss, who lives in Bern (Switzerland) and enjoys playing online chess. |
By unit tests using Google Test |
Insulin Pump System with two MCU's (stm32l476xx & stm32wbxx) |
- Visual Studio Code
- SEGGER J-Link
- Azure DevOps
|
1-5 minutes |
The rules are based on the MISRA C: 2012 standard |
When the nesting has more than three levels. |
The code reviews are done by a reviewer using the pull request feature of Azure DevOps. |
30 |
50 |
20 |
I love the variety of the work. There is always plenty of opportunity to learn, either through your own research or through courses. |
The search for the cause of an annoying bug that is almost impossible to find out about. |
Not so much, so it makes sense to attend this training class. |
Because my boss signed me up. But it certainly makes sense to increase our quality. |
Show
|
| 4 |
6 |
C |
Java |
JUnit
CppUTest
GoogleTest |
I like riding bikes! |
On unit-test level we are using CppUTest. |
We are using a 3 cpu system |
Eclipse
VisualStudioCode |
11-30 seconds |
Interal Coding Guidelines and MISRA2012 |
I do not like to scroll in functions, so if i have to scroll i easaly loose the context. |
Code reviews are done in Pull Requests of Azure Dev Ops by a technical leader. As a basis there are review report templates bound to our internal processes. |
30 |
20 |
50 |
I like that there are almost no limits of what you can do. I made the experience that even if you think you got the best solution for something, there is another guy around the corner which has a better solution for it ;) |
Due to the fact that a lot of people belive that software can always and at any time be changed easily there are most of the time a lot of changes during development. I do not like to fight with a fragmented software that grows and grows. |
There was once a motivation in the team to switch so i bought actually your book and tried it out in small examples. But it never made it "fully" to the project. What i tried to keep for me is to think first about what i really want before coding. |
In my small exercices with TDD i saw the benefit of thinking about testing in advance to not get untestable code in the end. It even influenced the way to design software items. I would like to get a deeper knowledge ecspeccialy when it comes to HW. |
Show
|
| 1/2 |
3 |
C |
C++, Python |
No unit test harness used in the past. Rudimental steps with CPPUTEST done. |
I have a background of mechantronics and electrical engineering, but during studies always focused on the "hardware/software interface".
I don't have much experience of nice greenfield SW development (e.g. creating a SW Module from scratch). But I consider myself to have good debugging skills, as I worked in a very late stage project in the atuomotive area, where had a lot of bugs and little knowledge about the ideas behind different implementations. |
We are at the moment in the setup phase of our project.
We plan to use Google Test for Unit tests. And we want to have automated integration tests by using Robot Framework.
In my past projects testing was mainly done directly after implementation, but for my feeling mainly rudimental tests. There was a seperate System Test deparment. |
Embedded platform for ethernet fieldbuses. The plan is to use C++ where possible. |
Static Code Analysis
Azure DevOps
|
31-60 seconds |
Plan ist to apply naming conventions according to "Clean Code" for example.
Technically we want to conform to MISRA C and AUTOSAR C++ Guidelines |
It doesnt fit on the screen anymore. |
Currently in setup phase of the project and no fixed process is implemented so far. |
40 |
20 |
40 |
The whole workflow from simple requirements to functional products.
I also like the complexity of the whole topic. From build environments over source control to actual coding. |
It is hard to tell if a the way we choose to do things will be considered as a good decision in the future.
SW modules always seem to be fine in the beginning as long as they are small and the person who created is available. |
That it is a really different approach of development, where you have to get used to it.
It is one of our best shots to create maintainable software |
It is part of the companies strategy to allign the development approach, therefore it is mandatory for every new developer.
I'm glad about that, as it is hard to convince a non-software aware manager of the importance of such a training :) |
Show
|
| 8-ish |
40-ish |
C++ these days |
C, Java (and long time ago, Lisp) |
CppUTest |
I'm passionate about developing quality software, done "right" the first time so it can be used forever. What better way to save time than to reuse software you know you can trust? |
Unit tests are executed during the build. Higher-level tests are still largely manual and/or ad-hoc. I'm seeking to improve this at the organizational level. |
Military vehicles, ranging from microcontrollers to desktop-level machines. |
Eclipse. |
11-30 seconds |
It's centered more around good software practices than syntax. |
When it's doing more than one thing (although "thing" isn't easy to define in this context). |
We need better participation. Authors need to do a better job making it easier for others to participate.
We also fundamentally need to reduce the need for them by adopting better, more modern practices that include a lot more testing. |
60 |
20 |
20 |
The creativeness of a good design. Technical brainstorming sessions. Communicating verbally with others. |
Maintaining poorly-written software. Throwing documents over the wall. Doing anything that doesn't add value. |
My understanding is it's based on tight time loops between developing code and the associated unit tests. I'm a big fan of design-by-contract (interfaces first), so I'd like to get a better understanding of how these ideas relate. |
As a new technical lead at the organizational level, my goal is to bring automated testing into our processes at every level. I see code-level TDD as one piece of that, and I'd like to get ideas for extending those techniques to higher levels. |
Show
|
| 2 |
20 |
C |
Python |
pytest |
I'm an embedded software engineer. I worked several years in with real time hard-constraint software for radio communication. I'm now working since 2.5 years in the medical field. |
Depends on the project. In the project I am now: program the device, hope it works. The testing team will do the unit tests later. |
Medical device containing two microcontroller (one main, one supervisor) and bluetooth connectivity. It injects drug. |
VS Code / Eclipse, Parasoft, C, Azure Dev Ops, conan package manager |
5-30 minutes |
MISRA C 2012 + internal coding guidelines |
The coding guidelines of the company says: max 100 lines, and I think there is a max of 3 indentations. But this is not checked.
Usually it's more an impression: can my function be split into several smaller functions? Am I comfortable with it? |
Done in Pull Request in Azure Dev Ops. Sometimes thorough, sometimes not. |
4 |
3 |
3 |
It's "easy" to do anything. |
Depending on how the project is lead, it can go wild very easily and the "anything" of above can be changed to "crap". |
I used it in Python, but not as deeply as it is explained it your book. But I love the concept. |
My manager thinks it is good that the entire team attends it so that we will work better together. |
Show
|
| 21 |
2 |
LabVIEW, Python |
C++,Rust |
python-bdd, pytest, unittest |
involved in instrumentation system testing, regression testing, R&D development prototype testing |
pytest or unittest |
embedded instruments, proprietary serial bus interface, gui is touchscreen, outputs are relay contacts, 4-20mA analog signals |
Rust software, C++ embedded, python system integration test automation |
5-30 minutes |
python PIP |
use clean code principles (do only one thing) |
team reviews |
4 |
1 |
2 |
forces you to be logic and follow rules |
too many configuration options and unique rules |
basic principle that we need to write code that incrementally passes test units and will in the end be itself considered the documentation and verification tasks fulfilled. |
as a tester, I want to use proven method to deliver quality software with less bugs and in short time. |
Show
|
| 3.5 |
14 |
C# |
C, Bash Script, Python |
None |
I like PC games, strong lift training |
I test it manually and we have a test team |
Congatec QSeven imx6 running Linux |
VS 2019 for C# |
5-30 minutes |
I try to follow https://www.dofactory.com/csharp-coding-standards |
If I need to scroll to see the whole function then it is too long. |
Code review is done mostly if there is a big change. |
50 |
25 |
25 |
I can be creative and have fun while doing it. |
Lacking of documents. Bad software design. |
I know the principles. |
To learn how it should be used in embedded sw |
Show
|
| 9 |
30 |
C |
C#
C++
bash script
Matlab |
- |
I like to work with software close to the hardware. As a hobby project I have built some smart home gadgets that I control with OpenHAB. |
I test the code manually before I pass it on to the test engineers. |
A YOCTO linux systems that communicates with nodes that contain STM32 microcontrollers. |
Visual Studio
Qt Creator
STM32CUBE IDE
Texas Instruments CCS
Matlab |
11-30 seconds |
Previously I worked with MISRA C 2004, so that is still a bit back in my mind :)
Other than that we have an unofficial coding standard:
https://www.dofactory.com/csharp-coding-standards |
If it does not fit on the screen. |
We work with GitLab. When we want to commit larger changes, we normally create a merge request and ask a colleague to review the changes in GitLab. |
40 |
30 |
30 |
I like it that you can come up with smart solutions for complicated problems. |
Writing documentation. |
Not so much. I know that the idea is to write tests before writing the code. |
I am curious to learn about TDD and I would like to introduce it from the start of the next project (which is coming up soon). |
Show
|
| 5 |
8 |
C# |
C, Python, Javascript, Powershell |
Unit Tests using MSTest Framework |
I work on N-Tier client-server applications, including microservice architecture, Database integration via ORM |
Unit Tests, UI and integration tests are done manually |
Windows, Linux, Mobile Devives |
Visual Studio |
Under 10 seconds |
writing reliable, clean and secure code |
if I have to you the mousewheel more than once |
I dont have time for code reviews nowadays, they were done when I started programming |
70 |
10 |
20 |
Being able to code software and develop solutions that make things easier to handle. |
Often solutions are not properly developed because of time constraints |
Basic concepts |
I was asked to join the course. I was happy to join because I always strive for self improving my coding skills to become a better programmer |
Show
|
| 15 |
20 |
c |
vb |
manual scripting |
work closely with hardware, system and manufacturing to make the products friendly, reliably and meet customer's uses |
fully from user standpoint |
Blackfin BF537 DSP |
VisualDSP++, Visual Studio 2019 |
1-5 minutes |
loosely enforce |
200 lines |
rarely review |
2 |
2 |
5 |
keep my mind fresh, demonstrate hardware working |
pressing deadline, issues happen last minute require staying late solving it |
fully feedback cycle to speed up development and testing software without actual hardware |
incorporate ideas to allow parallel developments, reduce test at each release and delivering something that i can be proud of. |
Show
|
| 6 |
20 |
C# |
C, Java, Python, Shell |
Ceedling (CUnit), NUnit, JUnit, Google test |
I enjoy being active (hiking, running, golf), (re)learning to play guitar and travelling |
Currently NUnit and Ceedling (CUnit).
Write failing test, write code behind the test, make the test pass, commit, refactor a bit where necessary. (I could use more discipline on the refactoring bit). |
It's kind of a typical pre-web embedded system comprised of a microcontroller for data acquisition (embedded C) communicating to a single board computer running a Windows C# application via a CAN bus. |
For the embedded bit, use Atmel studio (now MPLAB X), but found that CLion is a more navigable IDE (refactoring tools inclusive).
For the C# side it's Visual Studio with the Resharper plugin (for unit testing and refactoring/autocomplete tools). |
31-60 seconds |
We don't really have a coding standard. Part of this was practicality based as products were accreted from acquisitions - not practical to rewrite large aspects according to coding standard. My efforts are for smaller/testable sprout features |
When a function seems to do more than one thing, it's too long. When it handles multiple product variants as well as other things, it's too long. |
We don't currently do any code reviews. At best in Valley Forge, it is one developer per product/product line. Would like to start - emphasis on readability/testability over style. |
15 |
30 |
55 |
I like that ideas and pure math are the 'materials' to characterize the world around us, as well as the process of trying to adopt sound (read economical and succinct/correct) engineering practices. |
It's hard to clean up and 'pay' (via code rework) for messes by quick-fixes made in the past. I try to look at it as more of an opportunity to look for ways to not predict the shape of the code beforehand, but make it easy to work with when needed. |
I know that Kent Beck wrote a TDD framework for Smalltalk in the mid-90s. The practice makes sense and gives me (and the business) more confidence that something will work, and shortens the time to resolve what bugs do crop up. |
I've been doing TDD for about 15 years, but I want to make sure I am doing it properly, and learn more techniques (test-wise and design-wise) to build up a catalog of strategies to use for new designs so I don't burden the business with risk/cost. |
Show
|
| 21 |
19 |
C/C++ |
C#, VB |
None |
N |
Manually functional with unit or simulation |
Windows PC and embedded windows PC |
Visual studio |
31-60 seconds |
Not sure |
More than 100 lines |
By my self |
60 |
15 |
25 |
Logical thinking |
Knowledge gets outdated too soon |
Not much |
Want to learn the agile concept and apply in work |
Show
|
| 14 |
17 |
c |
c++, matlab |
unity, googletest |
I'm a softwaedeveloper with focus on algorithmic development |
unittests, software in the loop for Signalprocessing |
Devices: Digiphone, ESG, Ferrolux
Software written in C on a Blackfin from Analog Devices
|
Visual DSP, Cppcheck, Jenkins, Matlab |
1-5 minutes |
i'm using "my standard" |
refactor to max 60 rows |
using ccpcheck to find defects |
40 |
40 |
20 |
i like to make a better product |
there is no teammate to review my written software to improve my skills |
i use it |
checking my self trained skills |
Show
|
| 14 |
17 |
c |
c++, matlab |
unity, googletest |
I'm a softwaedeveloper with focus on algorithmic development |
unittests, software in the loop for Signalprocessing |
Devices: Digiphone, ESG, Ferrolux
Software written in C on a Blackfin from Analog Devices
|
Visual DSP, Cppcheck, Jenkins, Matlab |
1-5 minutes |
i'm using "my standard" |
refactor to max 60 rows |
using ccpcheck to find defects |
40 |
40 |
20 |
i like to make a better product |
there is no teammate to review my written software to improve my skills |
i use it |
hecking my self trained skills to |
Show
|
| 8 |
13 |
VHDL |
C, C# |
Non |
. |
Manually check the functionality. |
Self-developed PCB board, controlled by an FPGA. |
Intel Quartus II, Visual Studio |
31-60 seconds |
I code only a few lines and then test the function. |
Admittedly when I get the feeling that the code has become too long. I don't have any rules for that. |
I'll give the code to a colleague to test.
|
20 |
40 |
40 |
Develop software to make difficult and complicated tasks be solved. Be creative. |
Long debugging sessions. |
Not very much: Before coding you define tests the function later must pass. These tests are automated. |
As part of the Meggerwide SW Group and as a firmware developer I am interested in improving code quality and easing the test procedure. |
Show
|
| 6 |
20 |
C++ |
Bash
C
C#
GML
Java
Matlab |
Custom frameworks |
Outside of work, I also enjoy writing software. I have recently started experimenting with the game programming. I hold the code written in my personal time to the same high stanadards that I hold the code written at work, and share many techniques and processes between the two. Working in different problem domains gives me new perspectives which can help me solve new problems.
When I'm not writing software, I enjoy camping with my family, and snowboarding with my friends. |
A combination of automated unit tests and manual testing on hardware. Historically, this has skewed mainly towards the latter, but in the last couple of years I have begun to test as much as possible via unit tests.
As a project team, we are looking to perform more automated testing on hardware. This is not something I have been involved with personally yet, but am looking forward to learning about it. |
We typically develop hand held products used for electrical test. These products often involve multiple processors, and need to be designed with safety in mind. |
Hstorically, IAR tools, but we're moving to GCC and other open source tools that play better integration with CI tools.
We develop primarily on Windows, although there is some Linux/WSL work (particularly with CI).
We also use Matlab/Simulink. |
Under 10 seconds |
We had some vague coding guidelines that were mostly suggestions, and mostly ignored. I developed a coding standard with input from the whole software team. This new standard is followed more closely than the old one. It is overdue for a review. |
If it's performing multiple distinct tasks it should be split. If it doesn't fit comforatbly in the editor window on a small monitor with other tabs and editor panes open, it should probably be split. |
We try to review all code that is integrated with the develop branch. There is no formal process for how. Sometimes it is done via screen share, sometimes via Bitbucket pull request. Reviewees nominate a reviewer familiar with the subject. |
70 |
20 |
10 |
Solving problems
Creating clean/flexible solutions
Seing a project come together |
Hunting for bugs in poorly written code
Weighing up the pros and cons of tidying up poorly written code
Making the same points over and over again in code reviews |
I know about the basic cycle of test-code-refactor. I have tried to practice this where possible, however, we currently have a lot of legacy code that cannot easily be unit tested. I am trying to refactor this code so that it can be unit tested. |
The company is looking to adopt Agile processes for software development. TDD is a crucial part of this. I have shown an interest in the subject, so was nominated for the course. |
Show
|
| 6 |
6 |
C |
Python |
None |
electronic engineer |
None |
STM32 and Atmel range of microcontrollers |
Atmel studio, System Workbench (STM32) |
11-30 seconds |
None |
None |
None |
10 |
20 |
20 |
Making new ideas work |
Difficult to be organized |
Nothing |
Curious, need to learn TTDt as it is becoming mandatory in new development. |
Show
|
| 4 |
4 |
C++ |
C, matlab, python, C# |
matlab, simulink, xUnit |
... |
I currently mostly test simulink models (from which c++ code is being generated) via matlab scripts: framework inheriting from matlab.unittest. |
The system is a electrical measuring instrument which has two microcontrollers: STM32F7(GUI) and STM32L4R5 (measurement) |
matlab/simulink, visual code, gcc (wsl on windows 10), stmcube ide |
1-5 minutes |
It has been voted on by most firmware engineer in the team and it quite comprehensive. However, It needs to be updated for newer features of C++. |
Well, we have a recommended maximum of 50 lines for functions/methods in the coding gidelines so it's as good as a referential as any. |
Our code review are either informal (just one reviewer without any records of any requested changes when the original work is relatively small) or done using pull request on bitbucket when the work is more substential. |
33 |
33 |
33 |
I like solving problems as well as design new things. Developing software/firmware allows me to do that withing a relatively well defined scope. |
Having to maintain untidy code and some limitations from the tools. |
I am familiar with it using the matlab/simink framework, have put together a few tests once when writting a desktop C# program and I have maintained a few unit tests. |
I have bought the book (Test-Driven Development for Embedded C) a couple of years back but have not gotten around to finish it during my free time. I figured this course would give me a nudge as well as some additional perspective regarding tdd. |
Show
|
| 3 |
4 |
C |
Python |
Very limited use of google-test |
Like tinkering and solving problems. Can enjoy looking for bugs in my code :) |
Have started testing with google-test on new code. Code that is being reused is currently hard to start testing.. |
Embedded arm microcontrollers, controlling all kinds of hardware, sensors, motors ++ |
VSCode
STM32CubeMX
CMake, Ninja, arm-gcc, openocd
|
11-30 seconds |
Historically has been no coding standard. But latest years we have begun adopted a company-wide standard. Auto-formatting of code is also used. |
When it can't fit in the screen... |
Policy to use 1+ reviewers depending on what has changed. Code needs to be approved (most cases) before it can be merged. |
50 |
30 |
20 |
The feeling when you solve a challenge in a good way. |
When you have been debugging your software for hours and find out it's a hardware bug. |
Nothing except what has been introduced following up to this course. |
Want to write better code. |
Show
|
| 0 |
3 |
C |
C++, Python, Matlab |
GoogleTest, BoostTest |
Mechatronics engineer who has primarily worked with motion control within oil/gas and military industry. |
Unittest with the Google test framework |
STM32 microcontroller |
VSCode, MinGW, CMake, Ninja |
31-60 seconds |
Guideline based on Google's C guidelines. |
When it breaks the character limit. |
Performed by code owner after merge request is sent. |
25 |
25 |
50 |
The problem solving aspect of it. |
Setting up development environment. |
Just the basic principles, write the test before the actual code. |
Software team lead arranged course to elevate the proficiency of the entire team in regards of unittests. |
Show
|
| 1 |
4 |
C |
None |
None |
Varied background from electronic, test development and embedded programming. Only worked 100% on embedded prog. in current work place. |
SonarCube + black/grey box module testing and functional test |
STM32 MCU |
Visual Studio Code / GCC |
31-60 seconds |
MISRA |
When it handles more than 1-2 logical operatins not handled by sub-functions |
Passed SonarCube screen, code is reviewed in meet with designated colleague with functionality and readability in scope. |
33 |
33 |
33 |
Like building things both FW and HW |
Nothing |
Not much |
Learn about TDD and hopefully improve the test methodology in own projects |
Show
|
| 0 |
10 |
C |
JAVA, C++, python |
none |
I have worked webbased application, embedded system. Also experience in threading and SQL. |
Manually |
Embedded System |
VS code |
11-30 seconds |
Follow the current pattern of the code |
No idea |
Peer review then senior programmer review |
20 |
30 |
50 |
logical part and development from scratch. |
very old code and not proper documentation |
No Idea |
Suggested by Employer |
Show
|
| 0-1 |
4 |
Pyhton |
C, Matlab |
Pytest |
I do not have much experience with proper software development approaches. I am curious and enjoy learning new concepts. I like the challenge to make my code work and look for bugs. |
Manual testing. I try to make my outputs very clear, so I am able to follow the execution. I use debugging tools to step through the code. |
|
Visual Studio Code, Pycharm, Git |
5-30 minutes |
I do not follow any standard. My initial aim is that the code work, then I try to make my code modular, descriptive and easy to read. |
when it's over 50 lines and I am still working on the logic of the function |
I need to clean my functions. I need to optimize my code as I work with it, do not leave it to the end. |
40 |
20 |
40 |
The freedom that allows you to explore and work on different fields. Most of the time you have access to different tools that allow you to learn new concepts. |
Planning how much time a task may take. Something simple sometimes may surprise you. |
I do not have much experience with TDD. |
I want to improve how I plan and structure my code. I lose a lot of time developing and debugging. I hope to reduce that by implementing proper testing, allowing me to see clearly what I need to focus on and test. |
Show
|
| 1 |
20 |
c |
python, c++ |
? |
- |
Debugger, test by using devices |
Atmel 8 bit mcu, PC, stm32 |
VS Code |
1-5 minutes |
- |
I dont like it to be longer that one sreen |
We use GitLab MR |
20 |
20 |
20 |
It is interesting to get the hardware to do what I want |
Discussions about unimportant details |
Nothing |
I want to know more about unit testing |
Show
|
| 1 |
16 |
C# |
C++,C,JavaScript,Python,SQl |
MSTest, Google Test, MoQ (mocking framework in C#) |
1) I am a smartass.
I was a computer science lecturer for a year (Datbases,Design Patterns,C++) , I enjoy complex challenges and I like understanding the 'why' of almost anything I use. I did a bachelor's degree in (technical) computer science in 2008, taught at the same place in 2019-2020. Was very happy to help introduce the concept of unit-testing. in 2019 I worked with some PhD students and helped make their code more testable/reproducable/documented,and porting Matlab code into C/C++.
I prefer to adhere to the unix philosophy, small simple programs, well tested, functional (no side effects and deterministic) whenever possible which means properly structuring code. Out of my 13.5 year career so far, 11 were in C# and 2.5 in C/C++. I shifted to C++ because C# was not sufficiently challenging anymore and too much focus is on 'simple' administrative systems in most C# heavyweight companies. |
I only did a little embedded here so far, there was no unit-testing, no regression tests, no gated checkin, no stubbing, mocking.. TDD.. forgive me for I know how I have sinned. |
Oof. I only did a bit of embedded. ATmega128, we don't really care about 'performance' that much, so careful thought into tailored code is often not an issue. Energy efficiency is not an issue, stack-size might be. |
I wish I could use e.g. valgrind.. GCC debug.. I like IDE's like CLion, but we often resort to Atmel studio and are bound to Windows ¯\_(ツ)_/¯ Visual Studio is still my favorite though. |
30-60 minutes |
I don't know what coding standard we use when developing C/C++ for ATMega. I just 'follow' along as best I can to keep the codebase consistent, and deviate intentionally towards best-practices and standards-compliance. |
Theory: Cyclo > 3, unless there is a good reason. MI4-index is below 80%.
Reality: spend 1+ hr understanding.
My ideal: unit-testing becomes complex or unfeasible; code coverage remains low. |
We check the style, but the code reviews usually happen 'after' a rather big chunk of work is done. We could be more agile, do not employ scrum. Code reviews are more of a feedback/suggestion oftentimes. |
20 |
10 |
70 |
Everything, especially understanding why something is not working properly. Also the knowledge of making something that can only be as good as I can make it; minimizing complexity while maximizing performance while maximizing maintainability. |
Maintaining code I don't understand. Often, I don't understand a function until I see it's unit-test. Lacking unit-test I must know all possible ways it can be called, recursively for all heuristic paths, which is improbable. It is scary. |
A lot, I think. I followed an extensive course 10 years ago. I have worked with pure TDD driven development/scrum and gated checkin for years. Within my current department, in C/C++ TDD is currently improbable by merit of lacking design. |
1: Was automatically added
2: I want to know how to do embedded mocking and stubbing and ask annoying questions such as "James, how would you deal with non-deterministic functions?, would you do unit-tests with random-data? or mutation tests?, UB?" |
Show
|
| 7 |
15-20 |
C |
C++, Assembly, Python, bat-script |
google test framework |
Self-educated programmer |
Mostly with manual testing |
AVR, ARM, x86, x64 |
Git, Visual Studio, clang-format, qt creator
(PuTTY, RealTerm, HxD) |
11-30 seconds |
Working code instead of following all standards (some shortcuts). |
Functions should not be more than one or two pages/screens long (except for very long switch cases). They should only do one thing. |
When I review others, I usually focus on execution speed/avoiding bloated code. I also enjoy code that looks tidy, and testable, if possible. |
40 |
20 |
40 |
Problem solving, understand how system works, dig into the low-level stuff, solving things at high-level |
Bloated and inefficient code. Long compile time. Ugly code. Getting many people to agree on a common standard. |
Some minor experience with google-test, but not used it actively. perhaps some minor experience during education. |
Learning how to use TDD effectively, in a way that fits my projects. |
Show
|
| 0,5 |
2,5 |
C |
Python |
- |
I love being outdoors |
Building, uploading and running it, and then create a situation where changes in the code will show. Sometimes I need to provoke the system or even introduce another bug to see how the system reacts. Then, if the change seems to work, test the change in multiple different situations/over a period of time |
Robot firmware mainly |
Git, Jira, Microchip studio, VS Code |
1-5 minutes |
We try to follow the same standards in code style and git use |
- |
We review git merges, or when someone is unsure about something |
60 |
20 |
20 |
It's challenging and the feeling that you create something |
Getting stuck with an annoying bug which you can't figure out |
Not very much |
Because I'm new to the concept, and me and my team think it's a good idea to join |
Show
|
| 2 |
20 |
C |
Labview |
None |
|
On bench setup or in real application. |
Autostore cube storage, automated logistics solution |
STM Cube IDE |
11-30 seconds |
|
|
|
50 |
10 |
40 |
|
|
|
|
Show
|
| 8 |
8 |
c |
assembly |
none |
. |
Tested manually. |
Bare metal embedded plattform. |
Clang, Git, GitLab |
1-5 minutes |
Ongoing, recently agreed on a proposal for a code standard. |
. |
Multiple reviewers are approving the code changes before merging into the master branch. |
40 |
20 |
40 |
Solve problems and develop products. |
. |
Basic knowledge. |
Hopefully to expand the toolbox to be able to develop more robust firmware. |
Show
|
| 6 |
15 |
C |
Python |
None |
I like pizza. |
With the goal of uncovering issues and bugs as early as possible.
Basically i'm doing manual unit testing. Manually manipulating input to modules/functions by any means in order to test all edge cases that I can think of.
In addition to this I would also do targeted/specialized integration testing before merging any code. |
Robot firmware running on STM32-controllers.
Requiring high degree of robustness and stability while also keeping focus on functional details.
Aspects related to performance and durability of the robots are important as well. |
Git.
Jira/Confluence.
SonarQube.
A bunch of internal tools. |
5-30 minutes |
Not well established at the moment. |
If a reviewer complains about it.
If sonarqube complains about it. |
Partly good. |
10% |
70% |
20% |
Being able to make things behave exactly the way you want it to behave. |
Not being able to make things behave exactly the way you want it to behave. |
That we should consider using it. |
I feel it will benefit me in doing my job more efficiently.
Unit tests may help reduce overall workload in the long run.
TDD may help with tracking progress and keep focus on the important aspects of the code. |
Show
|
| 0.75 |
30 |
Rust |
C, Python, C++ |
cargo test |
I am into amateur radio, maths and cryptography |
cargo test |
STM32Fx ( and some NXP ) |
gcc , VS code, git, rust |
Under 10 seconds |
rustfmt , still learning Autostores C standard |
It is less clear what purpose it serves, cyclomatic complexity gets high, line count. |
All merges should be independantly reviewd and pass CI |
7 |
2 |
1 |
Pushing the boundaries of what the hardware is capable, coming up with elegant solutions to complex problems. |
(Not) dealign with tecncal debt, restraints on what refactoring activity is "allowed", or there is to much siloing that prevents refactoring and streamlining APIs and integration. |
It is a SW dev. methodology that emphasises writing test early, and having complete (unit) test coverage. |
I think it will also provide useful information on HW and OS abstractions, that I believe will be useful for our code base. I will be following the course closely to try and capture some of the momentum that it may impart and continue pushing for it. |
Show
|
| 2 |
6 |
C |
C++, Python |
Cpputest, Unity/Ceedling |
Nah |
Some unit testing, a lot of manual testing |
STM32 microcontroller |
VS studio Code |
11-30 seconds |
More or less Linux style guide |
When I have to scroll |
Merge request before a branch is merged to master. Reviewers will look through the code and accept/decline. Build server makes sure the branch builds, but does not run any tests. |
20 |
50 |
30 |
Getting things to work |
Meetings |
Did TDD actively in my previous job |
Get to know more about how to organize unit tests. |
Show
|
| 1 |
10 |
C |
Matlab
Simulink
C++
Python |
Matlab
Simulink Test
utest.h (C)
Catch2 (C/Cpp) |
Controls Engineer. |
Simulation via Simulink - Requirements tests, integration tests, baseline/equivalence tests. And on target hardware / system. |
Embedded control system. |
Compiler
Debugger
Code Editor
Version Control (Git)
Simulator (Simulink) |
Under 10 seconds |
New. |
Based on experience. |
Often slow. But thorough. |
Don't know |
Don't know |
Don't know |
To solve a problem, requires a deep understanding of the problem. The understanding is acquired through study, experience and testing. It's fun when it's fast to test new ideas. |
When it's slow to test new ideas. |
tdd = write test before code. |
So the company becomes better at unit testing. |
Show
|
| 1 |
20 |
C |
C++
Python
|
GoogleTest, Robot Framework |
Software developer with great experience in the automotive industry. |
Testing directly on the target hardware. No unit tests as such. |
Embedded system based on STM32 MCUs for controlling robots for storage system. |
Eclipse
Visual Studio Code
GCC
|
1-5 minutes |
Development of code, and testing and debugging. |
Functions should not exceed 4 parameters (not to overload the stack) and not too many lines to make the overview of the function better. |
Code review are done upon merge requests by another software developer (lead) |
60 |
20 |
20 |
Challenging, innovative and technology is changing rapidly. |
Setup of development system and testing can be very time consuming and frustrating. |
Not enough I am afraid of. |
Because the company wants to improve automated testing and believe it is a good idea to introduce software developers to the idea. |
Show
|
| 1 |
27 |
C |
Python and C++ (looking at Rust) |
Google test and pytest. (Looked at Catch2) |
I like golf and beer (hear you are on Untapped :)) |
System tests, automatic jig tests and local happy testing. |
B1 robot is a multi CPU system with real-time requirements and a fair bit of dynamics (motor control). |
gcc, VS Code, pytest (for integration testing), Confluence for doc, Jira, git, Gitlab. Clang-format checks on commits (new). SonarQube for analysis |
5-30 minutes |
We're working on establishing a coding guideline for C as we speek, currently at draft level. We have established enough to automate clang-formatting, but we are still discussing parts of it. |
We have complexity measures in SonarQube - the problem is that the legacy code is way to complex so in practice it doesn't work at the moment. In my opinion it should be when it has more than one responsibility. |
We have MR (Gitlab merge request) that needs to be approved before they are allowed into the master branch. We have some preliminary checklists of what to check and are currently requiring 1 approver and preferably also a second reviewer. |
2 |
2 |
6 |
To create something |
Struggling with seemingly random faults, bad structure and I2C. |
It's a process where you develop tests before code in an iterative manner. |
Because I think we have a lot to learn as a group and an organisation! |
Show
|
| 0 |
13 |
C++ |
C, RUST, ASM |
Gtest, Gmock, munit (unit with a greek mu) |
I'm also a musician, I enjoy running and the outdoors. I read a lot of books. I enjoy making hardware-firmware hobby projects in my spare time with micro-controllers and embedded linux systems. |
GTest |
Not sure, I'm a new engineer at this company. |
VSCode, mingw, gdb/make/ninja, arm toolchain. |
1-5 minutes |
Not sure, I'm a new engineer at this company. |
Too many levels of indentation. Or - it's difficult to unit test (in that it's difficult to test it as one "unit", and requires convoluted integration-level tests to cover all codepaths. |
Not sure, I'm a new engineer at this company. |
40% |
40% |
20% |
Solving complex problems, and the joy of a functioning system. |
Time constraints! |
I've watched (and read) some Uncle Bob (Robert Martin), and his red-green-refactor method. I also followed strict TDD methodologies at my previous company. |
Self improvement (really!). I've seen the direct benefit of TDD in embedded systems at my previous company, and would like to continue my growth in this area. Now that I have this knowledge, working in a legacy untested codebase is so nerve wracking. |
Show
|
| 9 months |
15 |
C |
C++, C#, Python, ASM, Ladder, SFC, FBD, ST, IL. |
GTest |
All my experience is on embedded systems, worked with several micro-controllers such as PIC's, AVR's, etc.
Main experience with DSP, energy management, motion control. |
Gtest, GMock |
Bare metal Arm Cortex-Mx MCU's |
VS Code, Eclipse |
11-30 seconds |
We are in the process of implementing a company code standard. I don't have a strict standard, I try to follow as much as possible the legacy code standard. |
When I need to scroll the monitor to see all. But I aim for functions of not more than 20 lines. |
Before any merge request there is always min. 2 colleagues which go through the code for style and compatibility. |
50 |
10 |
40 |
It's very rewarding. The sensation of accomplishment when we make something work as intended never seems to fade off. |
It can be very frustrating, specially when we handle hardware that does not behave as expected/intended.
So in short: Debugging. |
I've read your book. |
I'm eager for knowledge. I want o see what is the process of tackling the challenges and try to learn by seeing what I do right and what areas can I work to improve on my flow. |
Show
|
| 2 |
5 |
C |
Python
C++ |
None |
I've never written tests for my code beofre |
By running it on the target. With debugger, print statements or normal operation depending on how much has changed. |
Embedded systems, STM32 |
Git,
Gitlab,
Jira,
Eclipse,
Visual Studio Code |
11-30 seconds |
Mostly focused on whitespace, naming, styles. |
When it becomes too complex to keep track of what it does. |
One or more relevant persons will look through the changes and confirm it does what it is supposed to and adheres to the defined coding guidelines. The author is responsible for testing the code and making any requested changes. |
unknown |
unknown |
unknown |
Lots of interesting, unique challenges. |
Debugging situations where unknown physical phenomena is affecting the result. |
You start by defining the interface, write test that test that the output is correct, then write the actual code. |
Because I was assigned to attend it.
That sounds unenthusiastic, but it's the simplest truth. I hope to learn enough to begin with test driven development and reduce time spent debugging and confirming a change didn't break something unknown. |
Show
|
| 3 |
6 |
C |
only C
Use C++ only as needed , so not very much |
NA |
Love to learn and ask questions. |
Bench testing (have a std set of instructions and debuggers) + we have dedicated team to do unit testing |
Linux |
Different IDEs |
31-60 seconds |
Our company and team has coding guidelines |
depending on what it is for
If there are redundant repeated parts, we create sub functions
Also make sure the function does not hold the controller( should be interruptible) |
We use code collaborator to do code reviews. Usually 2-3 reviewers+ moderator are present |
4/10 |
4/10 |
6/10 |
Its fun |
Its sometimes very stressful. When there's a deadline |
no |
I am good at C , but wanted to see if I get more understanding of C++ |
Show
|
| 1 |
8 |
C++, C |
python, Java |
cmocka, gtests suite |
n/a |
Depends on the feature/issue I'm working on.
For feature, I use T32/lauterbach to add breakpoints and verify the states of the variables. For issues I re-run the failing tests and recommend adding additional tests to increase coverage. |
ARM R8 based embedded system. Bare metal programming. |
lauterbach, ARM toolchain |
1-5 minutes |
c++11 |
per coding standards if it exceeds 50 lines |
n/a |
4 |
3 |
3 |
it helps to create a path in my mind. |
N/A |
develop testcase first and expect it to fail, then build SW to make the testcase pass. |
to refresh concepts and try to accommodate the knowledge in my project |
Show
|
| 5 |
20 |
C/C++ |
Python, ARM assembly |
. |
. |
Running on actual HW that has attached debugger
Pre-commit tools
Simulator
|
Enterprise SSD |
Visual Studio
GCC / GDB
ARM cross compiler / assembler
T32 debugging |
5-30 minutes |
. |
Check the readability of written code |
Peer review with review system |
20 |
30 |
50 |
. |
. |
. |
. |
Show
|
| 5 |
26 |
C++ |
C, Assembly |
None |
Working as embedded software architect. |
Run test cases |
SSD |
Lauterbach T32 emulator |
31-60 seconds |
We have a long list of coding rules. |
Not sure. |
Our code need be reviewed by at least one member from each of 3 groups. |
4 |
3 |
3 |
It can automate operations. |
None. |
It improves code quality and reduce development time. |
The job needs architecture design and TDD skills. |
Show
|
| 7 |
20 |
C++ |
None recently, Java, python. |
None recently, can't remember. |
DO NOT PROVIDE ANY CONFIDENTIAL, SENSITIVE OR EMBARRASSING INFORMATION IN YOUR REPLIES. |
Modify code to force code paths. |
DO NOT PROVIDE ANY CONFIDENTIAL, SENSITIVE OR EMBARRASSING INFORMATION IN YOUR REPLIES. |
IDEs, VI |
5-30 minutes |
DO NOT PROVIDE ANY CONFIDENTIAL, SENSITIVE OR EMBARRASSING INFORMATION IN YOUR REPLIES. |
When it becomes unreadable |
DO NOT PROVIDE ANY CONFIDENTIAL, SENSITIVE OR EMBARRASSING INFORMATION IN YOUR REPLIES. |
30 |
40 |
30 |
It's like a puzzle! |
Deadlines |
Not much |
Training class was provided to the team. |
Show
|
| 4 |
10 |
C++ |
Python
Bash
C |
None |
background in Firmware/Embedded.
|
bench test, some regression test cycles |
ARM based SOC |
lauterbach t32
UART
Firmware traces |
1-5 minutes |
Standard CPP codebase |
based on operations that belongs inside the function. |
code collaborator, standard review process with 2 peer and 1 moderator |
2 |
2 |
6 |
exciting work and find something new always |
could get frustrating and time consuming when its dependent on multiple factors and people. |
not much |
learn and improve development methodology |
Show
|
| 5 |
10 |
C++ |
C, Python, Assembly |
Proprietary solution, Isolator++ |
I like dogs, games, and pancakes, in no particular order |
Targeted testing / injection on real devices and in simulation environments, plus automated sanity test suites |
Proprietary SSD devices |
ARMCLANG, SlickEdit, Git, Visual Studio, make |
1-5 minutes |
Not comprehensive and selectively enforced. Based on internal preferences and design choices |
When I have to scroll to read the full function |
Some automated coding standard checking, but loosely enforced. Emphasis on correctness and functionality over style. Quality and scope varies depending on factors unrelated to the code (schedule, reviewers, etc.) |
80 |
10 |
10 |
Working on challenging problems that change daily, writing low-level code to interface with HW |
Unclear or changing requirements, prioritizing schedule over quality |
It emphasizes converting requirements to tests first and using the tests to evaluate software quality/completeness instead of coding first, then writing tests later |
I'm under the impression that it's mandatory |
Show
|
| 1 |
16 |
C |
C++, Python |
Only loosely explored python unittest, C unity |
~13 years of C experience at prior company; using C++ at new company with prior experience in grad school. |
Regression testing |
various:
SystemC model
Python models/parsers
NVMe SSD device FW |
VS Code, GDB |
11-30 seconds |
Loose for modeling code. Have not studied for firmware yet. |
When it takes effort to find specific functionality within prior studied function (multiple page ups/downs). |
varies: For model development, optional Bitbucket centric reviews. For FW, code collaborator required. |
40 |
20 |
40 |
Like working on a puzzle, and feeling good once it is solved. |
Processes (when more effort to check code in, than to write it). |
I like the idea in general of heavy unit testing, but have not been exposed to it much in practice, outside a few smaller self-driven projects. |
Registered as part of company training. I have had past interest in TDD, but my exposure has been limited to this point due to company culture in past (I can't speak for Samsung yet). |
Show
|
| 0 |
25 |
C/C++ |
C++, python, perl, bash |
cpputest, Unity |
N/A |
bench tests, debugger manipulation, integration tests |
Many CPUs, lots of hardware acceleration. |
VSCode, Trace32, home made. |
1-5 minutes |
it's reasonable. |
when the function name stops describing it. |
use of review bots is handy. can take a long time to get a review completed. |
40 |
40 |
20 |
N/A |
scrum. |
some. |
required. |
Show
|
| 6 |
8 |
C++ |
Python |
N/A |
N/A |
Bench test and putting breakpoint in the code |
I used Linux and windows both as target systems |
Source Insight for C++ development |
1-5 minutes |
I intend to follow the company-wide accepted coding standards |
if a function has many repetitive actions then I try to break it down and add another function to reduce lines |
I make sure to file a bug if I see an incorrect implementation |
30 |
40 |
30 |
Try to solve problems in SSD FW is my main goal |
N/A |
N/A |
I want to get better at C++ programming and writing unit testing to catch low-level software issues beforehand that could cause defects in the long run. |
Show
|
| 10 |
16 |
c |
C++ |
I would say not really used any recently |
I like to read architecture and design books |
using host applications developed by third parties or internal test teams |
Linux, windows based systems connected to SSDs |
ARM DS5, VS studio, Source Insight |
4-8 hours |
I follow coding guidelines set by company. Alone i have my own preference to see my code structure. prefer smaller functions, encapsulated. |
if i have to scroll page. Also company has standard set for lines. |
I look at code structure first then logic |
30 |
30 |
40 |
I like built systems. In process of development I like architecture, code design & debugging |
Requirements not being clear at starting, patches to fix requirement mismatch issues. |
Very new to it for embedded system, have done CPP-Unit at start of career but not too much. I used to write dummy test functions using cpp-unit to test my code ( module, function level) |
I would like to learn how to write and test my code without target system available.
Also expecting approaches help me in writing more clearer and leaner code. |
Show
|
| 2+ |
5 |
C/C++ |
python |
cGreen |
Firmware engineer, looking to strengthen my skills in C++ |
different team does the testing. no unit testing |
Samsung ASIC |
ARM, Bash, batch |
1-5 minutes |
-- |
-- |
reviews consist of syntax and logic verification. |
60 |
10 |
30 |
i like to see my code in action especially when target device is mobile. |
language complexity |
that we write tests first and then write code so that we know if code is in compliance |
i have less experience in C++ than C so to learn C++ better and OOP concepts |
Show
|
| 23 |
35 |
C |
C++, C#, Assembler, Python |
Self written, cmocka |
I am working as a SW architect and depending on the project, also develop components. Often analyzing issues with rare occurrences and develop test strategies for long term tests to find a solution. |
Test applications using the APIs of my code. |
Mostly embedded devices based on a ARM solution, with Linux or ThreadX. |
The toolchain for our targets based on the supplier delivery (SCons, bitbake, gnu compiler chain for the build system.
Lint and CppCheck for static code analysis. |
5-30 minutes |
Depending on the project, we use some team generated coding standards or we take over the standards from the supplier delivery. |
When i have to scroll up and down too much to understand the code. |
We mostly use GitLab. On older projects based on ClearCase, we use a ms-word review-template. |
40 |
40 |
20 |
It's always a challenge to create new functionality, to create fast and short code, to create power saving enhancements. |
Too much feature requests from the management without a real interest regarding the required efforts. |
From my understanding: Define an API, create a dummy and test code for that and the next step is to realize the real functionality. |
My team leader wanted me to attend and i want to see, if i already "live" the tdd approach (at least partially) and i hope to learn some more for approvement. |
Show
|
| 6 |
10 |
c |
used cpp and java earlier, currently limited to c |
python based |
My role was customization/support of protocol stack delivered from a supplier. Therefore I wasn't coding much in my current role, and I now perform the role of scrum master additionally. |
build, and afterwards by flashing the module, |
Wireless module, with a lwm2m client, connects to a web server and helps with provisioning of an embedded SIM. |
source insight, vim/gvim. +Qualcomm tools to debug. |
5-30 minutes |
most of my changes, I start from existing files, so the standard is more or less defined. |
during debug, when I find it difficult to track the flow. |
normally done in gitlab |
2 |
3 |
5 |
I like solving problems. |
In my current role of scrum master, there is a lot of overhead to sync multiple topics/ people etc. causing so much of context switches. the software is delivered from multiple teams, so too much dependencies. |
Nothing much. |
Planned by software head.
I'm not shy to try new things, an idiot who finds it difficult to say "no", all things added together possibly.. |
Show
|
| 21 |
21 |
c language |
bash, python (few), c++ (few) |
Sw Department wide:
Jenkins, Bash Scripting, Artifactory for storing logs, firmware versions, crash dumps. I have only partially experience with Jenkins. |
engineer for telekommunication, but not for informatik, I got used to programming in the company for hardware related topics, like power saving, battery charging and the last year to support the audio functionality in our projects. |
As unit test with bash scripts, with intention for automatisation in CI (jenkins). If not possible only manually. Especially for audio topics to recognize if audio path really enabled we have few sensor options to realize woking software. |
Embedded system with mostly ARM processor, main software delivered by processor producer, do we advancing the system and make it compatible in the customer environment. |
Source Insight, Notepad++, propiritary tool of the the processer producer (Qualcomm, Mediatek), git (last years), before clear case as version management |
5-30 minutes |
Department wide defined standard. |
At the moment it becomes unreadable or if it obviously that more functionalities are covered by on function. Review of sequences of the whole concept is very timerequesting and often no doable. |
Reviews in git lab: Check for syntax problems or obviously better to handle functions. To get deeper in the right |
6 |
2 |
2 |
To get features realized. To see final functionality. |
Build times, upload times, briefing of management about unfinished states. |
Nothing in detail. |
Delegation of software department. |
Show
|
| 23 |
30 |
C |
currently none. Over the years ... project dependent. ASM/C/C++/Java/Pascal |
cmocka |
-- |
As I am mostly bugfix others code or just enhance vendor code, tests are usually very specific. Often this is done by individual agreements (case-per-case) with system test department. |
several SoC's form Qualcomm, MTK, ... |
plain text editor + vendor specific env. |
1-5 minutes |
company internal rules. |
depends on development style. Some functions are really long but good to read. But yes: most functions are too long. |
project specific. Currently: most changes are to be reviewd by at least one another developer using gitlab. |
30 |
10 |
60 |
-- |
-- |
-- |
manager decision; but I think it is a good idea |
Show
|
| 20 |
20 |
C |
Python |
Jenkins CI server |
Working since years in embedded software development mostly in hardware related areas. |
Jenkins CI server |
64 bit ARM/Cortex processor for 5G products |
GIT,Jenkins |
5-30 minutes |
There is a confluence page which contains all rules. |
if function code doesn't fit on the monitor |
The code review is automatically initiated by pushing the code changes to the server. Sometimes it is challenging to understand the functionality when the review contains a lot of code. |
7 |
2 |
1 |
solving problems |
missing deathlines, documentation |
not so much.
Each coding step has to be verified with a testcase? |
I got a invitation from my boss. |
Show
|
| 20 |
20 |
C |
C++
Java,
Perl
|
Jenkins
cMoka |
i am working for HW related issues. |
Ci, Jenkins |
Several Base band Processor systems |
gcc, make, cmake |
5-30 minutes |
from supplier company |
If it not efficient and do much more than it should. |
Gitlab tools |
60 |
20 |
20 |
introduction of my own ideas in to dev sw.
Challenge to resolve problems |
long compiling and test times |
|
learning more about tdd. |
Show
|
| 20 |
25 |
C |
C++,Java,Python,Perl |
Jenkins, Android CTS |
Since several your in specialized in hardware related software development. |
Jenkins, CTS |
Android |
Compiler, Source Insght, Lauterbach debugger |
5-30 minutes |
Defined by the company |
Hard to say bcause we mostly work on existing code |
Organized with Jira tooling |
20 |
60 |
20 |
Its creative type of work |
Sometimes not easy to understand and debug existing code |
Partially already used in our company |
Hopefully we can improve the ttd we use. |
Show
|
| many |
even more |
C |
ASM, C++, CMM (JTAG debugger control scripts),
Script Languages for Win Command/Power Shell and Linux Shells (Bash),
Python, Perl |
Jenkins
CMoka |
I'm a specialist for hardware related software (Device Drivers in general, Interface Driver and Protocol (e.g. USB), Operating System) and system debugging (Multi-Core real-time debugging via JTAG, Post Mortem Analysis). |
manually |
Mobile Phone SOCs |
several |
30-60 minutes |
Most of the software we handle originates from external suppliers. We mainly commission and stabilize, only sometimes adapt or extend the software.
We have a collection of articles relevant for our work in confluence. |
A function is to long if it is further divisible on a given abstraction level (or layer).
Rule of thumb: a function should fit on a screen. |
GitLab based merge requests
documented in Jira |
33 |
33 |
33 |
Always new challenges, never gets boring. |
Being given incomplete requirements too often. |
Start with describing testable functionality. Define Test Cases by splitting down functions as far as it makes sense from the point of view of the user/customer. Having defined Test Cases start thinking about software design and implementation. |
Because my department leader asked me to stand-in for a sick colleague. |
Show
|
| 20 |
37 |
C |
Perl, C++, Clojure, Racket, Java |
cmocka
|
I'm an old man if you know what I mean ;-) |
unit tests, on target tests |
various vendors using different OS, e.g. Siemens, TTPCom, Qualcom, MediaTek, Intel |
gcc,g++,vendor compilers, ...
make, cmake, scons, ...
gdb, Lauterbach, language debuggers
vim, emacs, SourceInsight, Eclipese, ...
gprof, gcov
ClearCase, git, mercurial
Jenkins, Gitlab, Jira, Confluence, ClearQuest
...
|
1-5 minutes |
company provided one |
when it is longer than a typical editor window
|
using Gitlab merge requests |
50% |
30% |
20% |
being creative |
when I have to use boring tools |
I bought your book some years ago ;-)
|
my manager forced me
|
Show
|
| 0 |
33 |
Powerpoint :) |
C++/C/C#/Java if I have to/ruby/python/etc |
CppUnit, JUnit, Nunit, Xunit, all the little units |
I hope you know me by how :) |
I write every line of code imaginable, as fast as I can, and use a binary search to find the bugs |
sdf |
asdf |
11-30 seconds |
asdf |
When it is more than one line |
asdf |
45 |
45 |
10 |
Building something out of nothing that serves someone's purpose |
Java :) |
A thing or two. We may have learned it about the same time... |
So I can help coach the team in the long run |
Show
|
| 18 |
30 |
c/c++ |
not much else |
? |
I don't code much anymore - in management |
unit or bench test by developer and then test cases by test group |
Linux Debian or VxWorks |
workbench |
30-60 minutes |
it is old |
candidly doesn't fit on 3 screens or less |
performed with each release |
0 |
0 |
0 |
everything |
nothing |
have some ideas - but i am probably wrong |
get exposed to TDD |
Show
|
| 10 |
0 |
python |
na |
na |
Manager of HW/FW group |
internal group |
cellular tracker devices with various sensors for perishable and healthcare market |
na |
Under 10 seconds |
na |
na |
internal |
0 |
0 |
0 |
na |
na |
nothing |
to learn different agile approaches |
Show
|
| 23 |
28+ |
C++ |
C, C#(D♭), Objective C, Pawn |
None |
I've lived a number of places, NC, NW Jersey, Chicago, SLC, Fl, Madison Wi, pvt pilot, musician, Married with cats! |
Testing by running on target - testing function and unhappy paths. |
Linux on arm, VxWorks on X86 |
Eclipse, Workbench/Tornado |
1-5 minutes |
We use an internal standard partially followed these days |
When it more than a couple of pages. |
We do them, from an internal check list enumerating items to check. |
35 |
50 |
15 |
It's fun to breath life into systems, the creation process. |
Not having firm and correct requirements. |
nothing |
I believe we were asked if we were interested or drafted, I can't remember... :) Really, always interested in learning more and improving - sharpen the saw. |
Show
|
| 4 |
12 |
C# |
Java, Structured text, Ladder Logic |
NUnit |
Optimistic developer - still believe my code should compile on first try and run without bugs the first time :-) |
I build my own testing classes/blocks/methods/functions to unit test my code vs expected results. |
Windows, PLCs/Controllers |
For my current job I use ISaGRAF, VS Code, Visual Studio and StarTeam for version management. |
1-5 minutes |
We have a team developed code standard we follow. |
Can't fix in one page/screen. |
Code reviews with peer developers. |
25 |
45 |
30 |
Always fun to tackle a new programming task. |
Scope creeps late in the game. |
Very little: Code well-defined pieces of code and test them right away. When they passe testing it can be re-used/called by other function/modules without re-test. |
To hopefully learn something to add to my arsenal as a developer. |
Show
|