Why I have not rejoined Broadcom

July 28, 2024

In the beginning of 2023 I was looking for jobs about static code analysis and in turn I started working at Broadcom.

The text below presents my experience. In other departments in Broadcom under the same conditions things might have run in other ways. That is: Broadcom might provide in general not the work environment described here.

Good things first: I appreciated that there was no stress at work and there was never pressure on me to deliver faster, there were no deadlines or intrigues, no finger pointing. Everybody tried to be constructive. The computer I received allowed me to do pretty much everything I needed.

After I started, I was supposed to read the reports of a particular static code analysis tool, and address these. One type of error was a real or hypothetical memory leak. Hypothetical memory leak means that in the way the code was written, there was in fact no real memory leak. In such cases I rewrote the valid code to silence the static analyzer. Or the hypothetical memory leak was in code, which was never executed.

At that time I decided that it is more practical to fix memory leaks, which really do happen at runtime. According to the workflow, I was supposed to propose changes to the code and somebody else approved the changes. The changes I proposed in code, based on real run-time memory leaks, were postponed, as these were not a priority, while the priority was to fix the warnings reported by that particular static code analyzer tool. If I remember correctly, also grammatical errors in the documentation, or corrections of the examples in the documentation (to make these working), were in the same way not a priority. At one moment I was told that I am hired because of the used tool for static analysis and if that tool was not used in the company, I would not have been hired.

After I fixed one memory leak, reported by another (open source) tool for static analysis, I was asked how I found that leak. In order to avoid criticisms, I replied that I discovered it just by reading the code.

I said to my colleagues that in my eyes first the compiler warnings should be addressed, then the run-time errors (memory leaks, reading of uninitialized memory) after compiling the code with sanitizer/instrumenting it, and once all these are handled, then static analysis should be applied. (As well known, static code analyzers do not validate all possible codepaths. Tools with big marketing budget do not discover every problem.) It was irrelevant what I said. My colleagues were expecting from me to work on the errors found by the chosen static analyzer, because this priority was set by higher management.

At some moment I asked for names of higher management to explain that the set priorities are not good. I received no names, but there was a meeting to recharter the priorities. One of the things I said there was, that the list of compilers, which are able to work with the product should be fixed, so that it is clear which language standards can be used when writing code. By the time I left the company, nine months later, no such list existed. In any case at the end of that meeting everybody could vote for what should be a priority out of many proposed ideas. I was the only one who had not voted for “More tests”, but “More tests” got the most votes. Months later nearly all of the voters have not written any tests, and it was me who was writing more tests. I think democracy is good, but democracy in that particular meeting was not good.

I provided hints over months, that I do not want to write tests, nothing changed.

The product I worked on is old, written theoretically in C++, but most of the code in the .cpp files is in C. The software did string management with strcat, strcpy, vsnprintf, fixed size buffers. The static analyzer wanted to see instead strncat() and strncpy() and in fact I was replacing strcat() with strncat(). If I remember correctly, my proposed changeset for introducing vasprintf() was overseen for a pretty long time and I do not recall what happened with it.

At some moment I suggested using std::string, because strcat(), strcpy() are error prone and the code is anyway C++. I suggested it several times and there were many discussions on this. During the final discussion the majority concluded that switching to std::string would be a significant change and we want to keep the changes minimal. After that final discussion it was not a good idea to bring up the same topic again. Many from the majority, who wanted to have ”minimal changes”, have not touched the codebase very much, and later asked me for C: what means L an the end of a numeric literal; how to find out if a \0-terminated string is empty; how to split a long line (macro) in two lines. Whenever I started a discussion for a topic, it was appreciated that I brought the problems up, but the result was always that I could not decide on anything and whenever I proposed something, my proposals were rejected, unless the only other person who could program in C also agreed. But if that person had agreed, which was clear off-list in advance, there was also no need to have a discussion. So I saw no point in starting new discussions, as they only proved I am always wrong.

The tool for static analysis has also reported a potential buffer overflow on user input. At this time the possibility to switch to std::string was already not an option, but fixing the buffer overflow over all the involved functions (presumably with malloc()), which used fixed length arrays, would be a too big change. So one of the options was to emit an error and abort the program in the rare cases when the buffer was too small. Then management started explaining that such terminations (on buffer overflow) will modify the program behaviour, users were used to, and is therefore not good. The total time for this discussion, and its preparation, counting the time of all involved persons, would have been similar to the time to rewrite the relevant places to utilize std::string and get rid of the fixed length arrays. But hey, the majority already concluded that std::string is not a good idea. At the end the product was reprogrammed by me to abort on buffer overflows, even if I had preferred with reasonable efforts by std::string to fix the potential buffer overflows.

The product we developed was compiled for more than one operating system. After modifying a single fix many times, eventually in its final form I proposed a change, which broke the build for one of the operating systems. This change was approved. Then the approver realized what happened and proposed a fix, but was not entitled to self-approve that fix. I was also not authorized to approve the fix. The ones who were entitled to approve the fix, have not done so for six months. So for half a year nobody from the team (the ones who can approve changes) had a problem that the product, as present in the version control system, was not compiling for one of the target operating systems.

The product was supposed to get a big refactoring. Refactoring is not the correct word here to understand the rationale for the huge changes planned, but I do not want to publish insights for that product to explain the reasoning. This led to a logic, with which I partially agree, where the code should suddenly not be modified (e.g. by fixing bugs), until the big change is performed. Or rather, if something is changed, the changes should be minimal. That is, if some code is never executed, it should not be deleted, but surrounded by #if 0 … #endif. On the other hand, another reason for the no-delete approach was that some of my colleagues had difficulties using git. I expressed a wish to work on that big refactoring, so that dead code can be deleted and bugs fixed, but was not allowed to do so, and nobody worked on it.

The product had a module, which could run in four different modi. While writing tests for it, I fixed the module to produce for the same input in all four modi the same output. I was criticized, why I have prepared corrections for that module, instead of only writing tests and describing in the ticketing system the problems I encounter. The problems should have been addressed, once the aforementioned big changes were done.

At some moment the company asked me if I am interested in a permanent position, instead of being a contractor. I replied it depends on the conditions. After a while it was said, I will get an offer for that permanent position after six months, later this was revised that I will get an offer next week. Two weeks later I was told that for reasons which have nothing to do with me, I will get an offer for a permanent position in two months. On the day after I was told that I will get an offer for a permanent position in two months, I quit. I said I have found an offer which pays now more and allows completely remote work, and what I said was indeed true. I was nevertheless hinted to apply for the opening in two months to get an offer. Even if that permanent position was never discussed, I would have exited on the same day.

To get that offer I was supposed to “apply” for it. At that time I decided that I cannot reject an offer, which I have not seen. But I also decided when applying for Broadcom not to submit any information, usually submitted when applying for a job, apart from a copy of my ID card. I mean - no information about education and prior work experience. I had no idea how I would avoid answering questions during the application process, about what my motivation to join Broadcom is, how I see myself in five years. At the end there was no interview.

I find it ridiculous that someone has to apply in a private company, where one has worked for a year, to get an offer for a permanent position from that company. When the position was opened two months later, I applied for it exactly as I planned. The system insisted that I upload a file with whatever information I consider as essential. The application system has not accepted empty files, so I put a dot in a file and by uploading it I completed the application process. Afterwards my former manager asked me exactly what high education I have, I answered him and on the same day I applied I received an offer with a start date in five weeks. I intended to accept the offer.

I was promised that after joining as a permanent employee I will be entitled to take exactly the decisions, which the majority of the team has in the past convinced (forced) me to abstain from. Moreover I would be allowed to work on that big refactoring.

In the new company I worked for, after I left Broadcom, I could not complete everything in five weeks, so I asked Broadcom if I could work part time in the first month after rejoining. This was refused. As it turned out, the offer from Broadcom implied penalties if I do not start exactly within five weeks, as suggested in their offer, and more penalties, if I do not start within ten weeks. I communicated that I will start within that five weeks.

Next I received a questionnaire and after “Education” I filled in “Irrelevant”. Then I was told that the information about education is collected for statistical purposes and this is stipulated by law. I replied, since it is anyway only for statistical purposes, that I have completed high school.

Then Broadcom requested me to prove that I have the high education I have communicated to my former manager, after applying at Broadcom. As I have decided, when I left Broadcom, not to submit any such things, I asked what would happen if I had said in the past that I had no high education. The reply was that this needed an approval from a person at a concrete position in the high management.

I explained that my understanding is that I got this offer based on the results of my work, demonstrated communication skills, attitude. I thought education and prior working experience were insignificant. I added that I asked the person in that concrete position to make an exception about education. And indeed I have emailed that person.

On the next day Broadcom withdrew its offer, saying education was important for this position, and mentioning that I have asked the concrete person in that high position to make an exception.

Usually I work (by accident) on projects with indefinite duration and decide to leave them after more than two years. I decided to leave Broadcom after one year. I have never before been that much restricted in my freedom to make decisions. This restriction is an indication that from the perspective of the company I am not capable of deciding correctly on anything myself. This is groundless mistrust.

While still at Broadcom, for a bug I have discovered, I proposed a fix. For half a year nothing happened, then I was asked if I could rewrite the fix in some different way. There were no concerns expressed, that the proposed fix is somehow wrong, but it should be made in a different way. I answered I have forgotten all the context and if I change it again, I will have to start anew. If somebody else wants to work on that bug, I am totally fine, but I am not going to do so myself. Afterwards the proposed fix was discarded without substitution.

Broadcom‘s logic is, that if I propose a fix, it can be discarded (after six months in the queue), even if there were no concerns that the fix is correct. If I however supply proof that I have higher education, then I will be entitled to approve that very same fix myself.

First I was convinced without having a choice (forced) to code software to terminate, in the rare cases when buffer overflow will happen, even if I preferred to allocate memory dynamically (with std::string) and avoid the buffer overflow. Afterwards Human Resources told me that if I provide evidence that I have higher education, I can decide to change the software again not to abort, but allocate memory dynamically, as I want. Who would do this, under such circumstances?

As for the higher education, it is of course irrelevant, after working one year for a private company. Broadcom wants to see evidence for it just to check if I am willing to follow rules, which make no sense.

As it turned out, the company did not want to permit contractors to do anything else except writing tests, handling reports from a single static analyzer tool and other minor things, like describing bugs, but not fixing them. This is to ensure that the long-term employees have the expertise and Broadcom does not know if it wants, or has the money to engage long-term with a contractor. Call it as you want, as I perceived it, I have been as a contractor unconditionally mistrusted and then I decided that I do not want to engage long-term with that company. I had no idea how I would regain my motivation, if I had returned.