DEV Community: Btara Truhandarien

Job Search In A Pandemic, Part 1

Btara Truhandarien — Wed, 02 Dec 2020 06:00:00 +0000

Recently I have just transitioned to a new job position (2 months ago from the date of this post) and the experience of the search served to be a valuable feedback for me. Now job search is not something I look forward to and doing it in a pandemic does not make me more enthusiastic. But due to personal reasons my decision to move to a new job was already set in stone pandemic or otherwise. I am sure I am not the only one that have been doing job searches during these hard times, so I feel my experience may bring some value to those that want to or still are job searching.

Background and timeline

For background I was applying software/data engineering jobs in Toronto, Canada when I was still in Vancouver, Canada. I finished my Masters program on early April and I was targeting for a job position by end of August, which is when I planned to move to Toronto. During my job search I was working as a software engineer for a company that knows about my moving plans. Due to situation I was mostly mass applying to all kinds of software engineering jobs, though my specialty and expertise lies in backend engineering. Here is my job search timeline:

Started applying for jobs mid April to early May and then stopped because of a combination of a lack of motivation, jobs that match my preferences and feeling that it was a bit too far from August.
Restarted looking for jobs early June, this continued up to the third week of August. Applied almost daily, 1 to 3 applications
By early july only a handful (around 5) of recruiters/companies have contacted me back. Phone call interviews did not go well. Decided to introspect what kind of jobs I really want and the value I can bring forth as an engineer
In late July got a phone call interview for a node.js developer position. Flunked that one, used it as an opportunity to learn
Got a phone interview for my current company in early August, and managed to get past. Interview with management a week after, used the time to read up on company further and studied several materials
Passed interview with management and recruiter was able to put me for the technical interview with the team on the next day.
Technical interview went well, but with some hiccups. Ended with an offer that I took

The rest of this blog post will be structured following the timeline I laid out above as each one has a different story to tell. Since it’s quite long I will break the blog post to two parts. Link for the second part will be added on later

Timeline #1

In mid April I was just finishing up my masters studies. Not wanting to waste time I immediately started to look for job openings. I decided to change some of the formatting of my resume to what I think is cleaner and better aligned to my goal of finding a software engineering job. I primarily used Indeed and LinkedIn for my job search and my searches were honed in to a full time job for software/data engineering positions. I’ve never really worked on a conctractual basis so I wasn’t sure if I would like that, and with the pandemic going on I wanted to find something that would be long lasting for a sense of security.

There isn’t much that happened during this period. I immediately noticed that many job positions were looking for more of a full-stack engineer and I really wanted to focus on backend. But since I do have a bit of frontend understanding (nothing modern or advanced) I soon decided to just apply to those that demanded full-stack capabilities, and even some that are purely frontend. Surely it is better to try and apply rather than not at all (right?). Of course, simply increasing the breadth of my applications did not mean it generated any positive results. Most of the applications I made were not receiving any replies, and if they were replied it was a rejection. Some of the reasons I came up for myself:

The employers weren’t interested in my application (this is likely the case for various reasons)
I was quite open in stating that I was looking for a job starting at the soonest on August/September and perhaps it didn’t fit with the employers timeframe
Some wild theory that companies weren’t actually looking to hire but just scouting

While I never really know the reason, it did leave me feeling a bit dejected. Nearing May, I got a phone call from the employer that I worked for during my co-op wondering if I can come to help them on their projects. I took the offer and became busy with work and left job search on the side thinking that it may be better to try and apply another time.

Timeline #2

In May most of my time was taken up by work and just spending my off-time relaxing by picking up some Switch games that I have neglected. When June arrived I noticed that I haven’t been looking for jobs ever since I stopped. There is only 3 months left until I move to Toronto and that felt too close comfort. It’s actually a bit funny thinking back on how a month’s difference makes my perception of time availability turn 180 degrees, from “I have time” to “I don’t have time”.

Trying to improve from my previous attempts at applications I decided to look back to my resume and cover letter once more. Some of the things that I did:

I noticed some inconsistencies in formatting and some grammatical improvements to be made in my resume
I put more emphasis on the job experiences that I wanted to highlight and be proud of by reordering them and using active words
I created several copies of my resume, only differing in the job title that I wanted to present myself as depending on the application
I decided to create a standard cover letter resume

You would think that one of the things that I would have done was to have a connection review my resume in the list above, but as you there is no mention of it. Why? The reason is simple, I was too afraid to ask it to be critiqued by another set of eyes. Honestly, I should have sought someone to critique it for me, but I was simply too scared at the thought of being shot down, getting told that what I have won’t impress anyone and overall deflating my confidence and spirit. Deep down I know I have some issues with imposter syndrome, and honestly sometimes I do believe that I am incapable. Some time in the future I would probably write another blog post about.

Timeline #3

Job search did not go well. The number of applications that resulted into responses can be counted on one hand, while in total I probably applied to at least 50 applications (1 - 3 applications per day, at least 5 days per week). The ratio of “success”, success here simply getting a reply, is less than 1-to-10, yikes. Furthermore, I was sure not able to impress recruiters in my phone interviews. At some moments I did think that maybe it was all because of COVID19 and the job search climate. But I decided that even if that was the case, it was something that I can’t control. No matter how much I groan, my groaning would not lead to the outcome I desire, getting a job. So I further expanded my effort to improve my application process.

I challenged myself to answer the following questions:

What kind of job I really want? Does industry matter?
What responsibilities would I best be able to serve in? What technologies that I know that can benefit the company I apply to?

Answering the two questions above I decided to stop applying to frontend-heavy jobs. I would still apply to a full stack positions, but mostly those that are more backend oriented. While this is doubling down on a specific engineering area, it is really where I want to be and where I feel I can contribute best as an employee. With that in mind I reviewed my resume and cover letter once more to change how I present myself.

My most extensive work experience were with messaging/event-driven and data streaming oriented systems which coincidentally I enjoyed and was partly the reason to why I took a masters program. Therefore I made those experiences my main highlight in both my resume and cover letter. There isn’t many applications that directly mention such systems, but I wanted to put myself forward not as an all-rounder programmer that has no specialty. I wanted to be seen as someone that has a specialty but also possessing a broad range of skills. The next major experience that I highlight is designing and building REST APIs, which at least gets mentioned a lot in job postings. Lastly, I made sure to put myself as a developer that cares for quality in my cover letter by putting some emphasis on TDD and other engineering principles.

But the highlight of this timeline must be this: I started blogging and putting time for personal projects.

It is actually no coincidence that I started blogging more from beginning of July. My lack of progress in job search led me to find other avenues I can make progress in. Blogging was one of those avenues I wanted to invest myself more in, and also a relatively easy way to gain a sense of progress. For the same reason, I also started to do more programming in my own free time. While it isn’t the progress that I need, I felt it was tremendously helpful to gain a sense of momentum in life and also combating my imposter syndrome. I needed to not just feel, but know and see that I am capable of doing something I can take pride and ownership in. Had I not decided to start blog more or code on the side, I absolutely believe that it would have been much harder for me to push myself forward and continue job search.

To be continued

This blog post has gotten quite long already and I don’t want to bore you to death with my life story. So feel free to close off the tab now, I will post the next part in the future. If you managed to read up to here, honestly thank you for reading the diary entries of a man on the internet. See you in the next part.

How do you deal with information and learning overload?

Btara Truhandarien — Sun, 06 Sep 2020 02:43:26 +0000

As people working in an ever-evolving discipline, we're encouraged to continuously learn and take in new information. We also know how information has proliferated so much and everyday there's just new information (or articles, blogs, topics) that keep popping up.

Personally, in addition to trying to keep up with software topics I also try to keep up and learn non-software fields too. But I find myself often getting sucked to click hell, using my time opening multiple links to materials that I find interesting or beneficial, but then never really getting to go over them earnestly.

Do you experience information/learning overload? If so how do you manage it?

Request Body Buffering With Spring’s RestTemplate

Btara Truhandarien — Mon, 17 Aug 2020 05:00:00 +0000

Background

I have been using the Java Spring framework for my work for a while now. I started learning the Spring framework while building a REST API application which had to connect to other remote services through their own REST API interface. While the Spring RestTemplate is currently only in maintenance mode and expected to be deprecated completely in the future, it was the first thing that I found for making HTTP requests in the Spring framework. So I just started using it out of practicality.

Now we often want to make log HTTP requests our servers make. One way is to put log statements everywhere we needed to make HTTP calls. One of the alternatives with Spring RestTemplate is to configure a logging interceptor. This way we can configure a global (or several) RestTemplates that have configured logging capability.

public class LoggingInterceptor implements ClientHttpRequestInterceptor {

        static Logger log = LoggerFactory.getLogger(LoggingInterceptor.class);

        @Override
        public ClientHttpResponse intercept(HttpRequest req, byte[] reqBody, ClientHttpRequestExecution ex)
          throws IOException {
            log.debug("Request body: {}", new String(reqBody, StandardCharsets.UTF_8));
            ClientHttpResponse response = ex.execute(req, reqBody);
            InputStreamReader isr = new InputStreamReader(response.getBody(), StandardCharsets.UTF_8);
            String body = new BufferedReader(isr)
              .lines()
              .collect(Collectors.joining("\n"));
            log.debug("Response body: {}", body);
            return response;
        }
    }

Taking from the Baeldung post above, we can see that the signature for the intercept method contains a reqBody parameter of type byte[]. This means that in order to log the outgoing request body, Spring has to serialize whatever we are sending to a byte array structure in-memory. Depending on the request body that you are sending this can cause memory issues, and perhaps even out of memory errors. Additionally it probably has performance impact to your application, even if a little. So it’s something that may need some considerations.

The problem

Now in my current project I have to relay uploaded files made by clients to another service through its API call. These files will potentially be in gigabyte size range. Still using RestTemplate I realize immediately that the application will run out of memory if I logged using the interceptor above. So I decided to create two kinds of RestTemplate, one that can is configured to log requests automatically and another that doesn’t. Additionally I used HttpComponentsClientHttpRequestFactory.setBufferRequestBody(false) to ensure that the application will not buffer the uploaded file that needs to be relayed.

But when I was functionally testing the application I kept running to out of memory errors when uploading a 1.5 GB file and no matter what I did I could not fix it. After investigating further it turns out that I didn’t know the SpringBoot Actuator is available in the classpath. One of the things that the Actuator package provides is metric collection of outgoing HTTP clients made by RestTemplates, which is automatically provided if we build our RestTemplate through the auto-configured RestTemplateBuilder provided by SpringBoot. That is if we created our RestTemplate like the following:

@Bean
public RestTemplate restTemplate(RestTemplateBuilder builder) {
    return builder.build();
}

then the metric collection capability is automatically configured. And of course the metric collection is done by adding an interceptor, to be precise the MetricsRestTemplateCustomizer is used. This interceptor is added to the RestTemplateBuilder I used above to build the RestTemplate, and therefore all of my requests made with the RestTemplate that wasn’t configured for logging was actually buffering the request body! No wonder I kept hitting OOM errors…

The fix

Well the fix is actually quite simple, I just built the RestTemplate without the configured RestTemplateBuilder provided and everything is fine! Well… in the end I decided to move the application to use WebClient instead. Not only it is the suggested API to use now, thus am building for a future proof application, I would still be able to log requests without having to be forced to buffer the request body. Though if I want to log the request body programmatically, I would still be required to buffer the request body, but that’s a separate issue for the future.

Challenging Technology’s Social Free Lunch

Btara Truhandarien — Sat, 08 Aug 2020 05:00:00 +0000

No, this blog post is not about how many software companies (and I think more and more in general) provide food budgets or cater free lunch or dinner to their workers. The free lunch I mean here is an assumed and taken for granted property that technology has. Particularly a belief in technology as inevitably driving positive social progress and change.

The belief that technology deterministically drives social progress (and implicitly social good or bad) has a name: technological determinism

I don’t think this view is held explicitly, but I do think at the corporate level there is definitely a sense that progress in technology is almost always contributing imore positively to the social good than negatively. At the very least we get that sense when we see the headlines regarding technology startups (often computer software/hardware related companies) are seen as the next greatest thing. Also how this optimism is priced in to their business valuation, and how they are marketed by the founders themselves when they pitch their companies. Some examples would be:

Why am I thinking about this now?

When I decided to go to university to study computer science my brother asked me, “why do you want to study computer science?” Back then I did not have any background in computer science, software or programming but I was quite decent in mathematics and I only know roughly that I computer science is related to math. I’ve also been a heavy user of computer throughout my life, so studying in computer science was a bit of a whimsical choice on my part. So I could only answer with “well I think it would be great to help people through software and computers” to which my brother responded with “But why do it through software and computer?” and there was no immediate reason that pops up in my mind.

As an avid computer user, computers have been tremendously useful and beneficial throughout my life. Never have I really thought of the negative implications of computers and software (aside from my mum yelling at me for using the computer too much). As I become a software engineer I felt my optimism towards technology (software specifically) is further magnified. But we’ve seen how more recent stories, government bodies, social groups, and even the technologists themselves have become more critical towards technology’s social effect. They have started to not buy in to the social free lunch of technologies as much.

When I went to DEV’s CodeLand 2020, there was a talk titled The Cost of Data by Vaidehi Joshi (you can CTRL+F to find it). Vaidehi gave a talk about how running your code on servers will lead to the use of electricity, which is often still generated by non-renewable energy sources. She went further and talked about the clean energy initiatives by top public cloud providers namely Amazon, Google and Microsoft. When the host and Vaidehi interacted after the talk, the host said: “The world of data and the world of climate change seems so far apart”. As software engineers I feel the same way, though I am intimately related to the creation of software and technology, its impact and its relations to the world around me can often elude me. While I focus in creating a software for a particular purpose, and often for what I believe as a good cause and purpose, I do not necessarily know and understand the full scope of the impact of the technology that I have created.

This mismatch between between an intimacy with creation and intimacy with effect is really the reason why I made this blog post. For this blog post I just want to create a more explicit awareness.

Acknowledging that lunch has to be paid

The skepticism towards technology is now more felt by me than ever before. Social progress and good is not so immediate and free anymore and efforts should be taken in order for the lunch to be properly given out. As technologists that create the technology I do think that I and many others are at the unique position to consider the kind of lunch that we want.

At the same time I acknowledge that it is hard to do. Not just in mental capacity and knowledge, but also in execution. Many of us work for a company or a boss that has set upon us goals and visions that may constrain what we can do. We may not feel that we are at the right place to make these high-level decisions of social impact, which may very well affect the business. Perhaps we feel like speaking out our concerns will jeopardize our job and career.

But at the end of the day someone will need to pay for the lunch. Someone has to put effort into creating a meaningful and desired social effect. I think it would be ludicrous for our stakeholders to bear the implicit costs of the products that we make. Imagine a grocery store that asks you to pay an explicit fee for the potential health complications you may contract from the ingredients they sell! Ludicrous I’d say. While I don’t think that technologists such as me has all the answers, and definitely not going to be the only one to be involved in the process, I do think we need to be more aware of it due to our unique position. Which I hope will translate to a more active participation in the construction of the desired social affects of the technologies that we build.

In the end, there’s really no free lunch.

Being An Early Mentor

Btara Truhandarien — Wed, 15 Jul 2020 06:33:55 +0000

NOTE: This is an almost direct copy paste from a blog post I made on my blog @ https://btruhand.github.io/blog

In my career so far as a software engineer I have had 3 opportunities to be a mentor for someone that is more junior than me. Sometimes this junior-senior status is established not necessarily by the capabilities and skills but more by my length of stay in the company. This was especially true when I worked in Japan that is known heavily to promote a seniority ranking of some sorts, implicitly or explicitly.

Considering that I have only been professionally in the field for 4 years, with no previous background to software programming before my undergraduate, is something I find a bit surprising even for myself. I feel blessed to have had the opportunity so early in my career and in this blog post I go over my experiences and thoughts on my role as a mentor

The first mentee

I was asked to mentor a new colleague six months into my first professional full-time career as a software engineer. By standards of total working experience this colleague was actually more senior than me, but I just so happen to have worked in the company sooner than him. This mentee was also quite adept in his tech skills, so aside from a few pointers about the team dynamics, projects, system overview I can't actually remember any specific piece of technical knowledge that I felt I was able to impart. Actually I remembered several times where I was surprised with what he showed me, for example a specific setup that he had for the terminal-based text editor Vim. I have no shame in saying that I actually learned some things from my mentee.

My relationship with this mentee was more akin to colleague buddies. We were both close in age and was very techno-optimistic (I'm less techno-optimistic now) and think that technological advancement is always the best. We thought that impediments to technological progress is always bad. We bonded over the frustration of not being able to use and try out more modern techniques or tools, because management would say its too risky. We would shrug them off as an evil that we needed to live with and begrudgingly dreaded whenever we had to work with parts of the system that was deemed ancient (even by the really senior members in our team).

Then, my relationship as a mentor had to end because I was scouted by another team. There is an inherent idea in my head that the success of a mentor is in how much one can impart their knowledge to the mentee and in this view I would say I had done a poor job as a mentor. But I take solace in thinking that I was a great and relatable colleague, hopefully.

The second mentee

A bit more than a year into my software engineering career I was again given the opportunity to mentor an incoming colleague. This time, my mentee was actually just freshly started work as a professional software engineer. She also came from a more research oriented background, unlike my first mentee that came from a more engineering oriented background. It was clear from the get go that as a professional she was very green in terms of software engineering standards and the practical skills. I didn't have to teach her to code, but at times I had to assist her in trying to understand one technical choice over the other. I do not know whether I was actually being an effective mentor, but often my mentee would come to ask me for assistance for her own project. When I had time to spare I would ask how she's doing and ask if she needs assistance.

Around this time my attitude towards code quality was also becoming more bullish. Still coming off from the assumption that technical progress is important, as important or if not exceeding at times to some business needs, I would at times be hellbent that some technical progress be included into a project. One such example would be automated testing and basic CI/CD, which we were greatly lacking back then. To the credit of my persistence, and also some heavy silences during
team debates, gradually my team started to adopt some of the ideas that I kept throwing at them. It wasn't perfect of course, and it wasn't smooth or complete either, but it got things going.

Reflecting on my code-quality-hellbent-saga I remember some times when I tried to directly impart this knowledge to my mentee, but uneffectively. I would tell her to revise her code several times, and then may in the end revert some suggestions back. Why you may ask? Well it was because I was also trying to learn the thing that I was trying to impart to my mentee. I had the drive yes, but I was rough in the edges and was more like a bulldoze trying to make its way through instead of being more like a worker ant and learning with and encouraging my mentee. I'm sure my team had their frustrations with me too and probably felt confused at times by my behaviour too.

The third mentee

The third mentee is more recent. In terms of technical skills this mentee is somewhere in between the first and second mentee, still inexperienced overall but not a blank slate. This time I have personally grown with regards to my technical skills from my time with my first and second mentee. I've refined my thoughts and experience a bit more and had more time to polish it. I still hold some strong opinions regarding particular positions related to the software craft, but I think I can say that I am more flexible than before.

I also try to be more accommodating and reasonable for my mentee this time, trying to explain things a bit more slowly and showcasing more examples. However, I do find myself to sometimes be a bit impatient with my mentee. It might be because of the experience that I had accumulated so far which makes certain things seem simple and easy for me. So when my mentee is not able to keep up with me I would sometimes say to myself "why can't he get this quickly?"

But a recent reminder that I'm not always right (and certainly not great) was when I was helping my mentee for the code design of a feature he was working on. At first my mentee suggested a very simple solution that would get the job done, but I said it would be too inflexible for future changes and prone to breaking. My mentee agreed and tried out my solution, made some unit tests and it seemed fine, until it wasn't when a more comprehensive integration test was conducted. Turns out I made incorrect assumptions in my solution, and my mentee's simpler solution would not have run to the same issue as mine. To be honest it did feel bad that not only was I wrong but also I led my mentee to an incorrect solution, but am glad that overall I managed to resolve everything together with my mentee.

Rounding up my experience so far

Reflecting on my mentorship experiences so far here are some things that I have taken away:

It is important as a mentor to actually be able to impart the skills that you are mentoring in. Being close colleagues with my first mentee was good, but I could
have been a much more effective mentor and support for my mentee had I had the skills to backup my position
A mentor is a teacher in knowledge, methods and also in conduct. If a mentee is to learn from a mentor, then a mentor should reflect the correct posture to learning
and be open to the need for growing themselves
Related to learning, I learned and am reminded that humility is so important, because we won't get everything right. We need to learn with humility and open to admit
our mistakes

To finish things off, there is a proverbial quote I like to say that goes like this (though I'm not sure where of its origins):

Above the sky, there is another sky

There will always be someone better than you, and so there is always room for you to improve and grow, even if you are a mentor and role model for someone

Re-thinking Mocks

Btara Truhandarien — Sat, 04 Jul 2020 05:00:00 +0000

These days I have mainly been using Java for my professional career (roughly I have been working with Java for a year). I also mainly have been using the Spring framework along with its additional libraries at work. One of the things that I enjoy with Spring is the dependency injection capability that it provides, primarily through the @Autowired annotation. This quick and easy way to do dependency injection is also further compounded in testing benefits as Spring also provides easy and seamless way to obtain these dependencies at test time (@Import and@ContextConfiguration to name a few) makes testing much easier. I also make a good amount of use Mockito which makes my development life much easier through mocks, and this post is about mocks and my experience and thoughts on them.

What are mocks

This question has been covered in a variety of other posts out there, one of which I found most useful to be Martin Fowler’s post. In the words of Martin Fowler himself:

Mocks use behavior verification, where we instead check to see if the order made the correct calls on the warehouse. We do this check by telling the mock what to expect during setup and asking the mock to verify itself during verification

At the heart of mocking is behaviour verification, which is the ability to assert what has happened during the execution of a test, and not just what the system under test has produced. Martin Fowler made a clear distinction and emphasis on this part which you can read up on his post.

Quick example

class ClassA {
    ClassB dependency;
    boolean shouldDoFunc;

    ClassA(ClassB dependency, boolean shouldDoFunc) {
        this.dependency = dependency;
        this.shouldDoFunc = shouldDoFunc;
    }

    void func() {
        if (this.shouldDoFunc) {
            this.dependency.doFunc();
        }
    }
}

class ClassB {
    void doFunc() {
        // do something
    }
}

// test code below
void test_func_whenShouldNotDoFunc_notCallDoFunc() {
    ClassB classB = mock(ClassB.class);
    ClassA classA = new ClassA(classB, false);

    classA.func();
    verify(classB, never()).doFunc();
}

The above example is extremely contrived but it just barely shows the use case of mocks. The call to the verify function says that we are trying to verifythat when shouldDoFunc = false, we expect that ClassB.doFunc will not be called.

The alternative to using mocks above would be to supply an actual instance of ClassB (not mocked) and check against the results after calling ClassA.func. Now in the above example no values are being returned from any of the function calls so no returned value can be expected, however often such functions causes side-effects. Common side-effects include calling some API that causes some change, changing the environment settings, performing DB changes such as updates, changing the state of ClassB and many more. Such side-effects are testable and verifiable (if there are no side-effects performed by the function I question why the function exists).

The positives of mocks

From my experience thus far using mocks is that it has been beneficial to create tests. Certain testing may require an expensive setup or verification procedure,which makes tests run slow but also developed more slowly. An alternative to mocks may include creating fakes or stubs (a separate kind of testing entity), which may also create additional development effort to make and also may require its own maintenance. Though a great deal of this benefit comes from the fact that many languages have a well-tested and prevalent mocking library.

Mocks also makes creating truly unit tests easier, and by unit here I mean tests that only put a single class/object under test. Mocks enable me to put the focus and attention of tests on the specific unit under test and not have to worry about the other interacting pieces. In the example above, the test is made deliberately about ClassA.func behaviour when it is in a certain state. In more complex objects under test, this makes some desired fine-grained testing much more approachable and manageable.

The negatives of mocks

The biggest drawback using mocking is it requires whitebox testing, in order to verify using mocks we need to know what functions are being called, which essentially bears down to knowing some level of detail about the implementation of the unit under test. Nowadays I think of this as reflection for testing. Reflection is the ability to inspect programming constructs at runtime of some code within the code itself. Often this involves passing in names of functions or fields in the form of strings to specialized reflection APIs. Since access is made via strings, IDEs won’t help you during refactoring which makes mistakes during changes in the code base harder to detect. Thankfully a testing is one of the tools we have to safeguard ourselves against our programming mistakes, until the tests start to fail us.

Using reflection capabilities requires the programmer to have clear knowledge about what is and isn’t present and bake that knowledge statically into the code and it is the same case when we use mocks. Now libraries like Mockito does enable the use of refactoring through IDE unlike reflection, but mocking doesn’t easily allow us to change the tests when the dependency calls in the code under test changes. This creates a mismatch between expectation and reality. For example, if inClassA above we change the call of doFunc to another function doFunc2, the test would still pass but for very much the wrong reason! The reality is thatdoFunc is no longer a dependency call being made, but the test still expects it as a call to be made and it just so happens the test was verifying that no calls were to be made. The following test would fail:

void test_func_whenShouldDoFunc_callDoFunc() {
    ClassB classB = mock(ClassB.class);
    ClassA classA = new ClassA(classB, true);

    classA.func();
    verify(classB, once()).doFunc();
}

but now the test fails for the wrong reason! The test will fail because the test is expecting the wrong thing, not because the unit under test is behaving incorrectly. This is test maintenance drag. Martin Fowler calls this the coupling of implementation and testing.

An alternative for mocking

One of the compelling alternatives to mocking is by supplying functions as parameters to the unit under test instead of whole object dependencies. The ability to passfunctions as parameters is called First-class function. Consider this example in pseudo-Javascript

function funcToTest(dependentFunction) {
    if (some condition) {
        dependentFunction();
    }
}

test_funcToTest_whenConditionNotMet_doNotCallDependentFunction() {
    // do something to cause condition to not be met
    counter = 0
    funcToTest(() -> counter + 1)
    if (counter != 0) {
        throw new TestFailed()
    }
}

The passed in dependentFunction is simply a function passed as a parameter that is called when some condition is met inside funcToTest. Notice how in the test we are also verifying the behaviour of funcToTest under some condition, similar to the example with ClassA. In both the test using mocks and first-class function we see that behaviour is being verified, and this should come as no surprise. We can think of objects as instances of namespaces/groupings for functions (with the ability to maintain and collect some form of internal state) and so when we pass an object as a dependency it can be seen as passing in a collection of functions. The difference is that when we use mocks we have to explicitly mention the dependent function we are interested in, while with first-class functions the dependent function is stipulated in formal syntax (scratching off the fact that it’s possible to call functions without their parameters in Javascript). With mocks tests can fail/pass for reasons of a mismatch between expectation and reality, with first-class functions that possibility is greatly diminished and if it happens is likely the programmer’s mistake.

However in reality I have not used first-class functions as an alternative to mocks at all. Much the reason is because it is much easier to work with objects andmocks in Java. Though Java does have lambda functions and the @FunctionalInterfaceit is not that fluid to create classes and methods that take in first-class functions all the time. But this is surely a technique that I would explore and be more conscious of in the future.

[Series] Experiencing Facts and Fallacies of SE - Stop! No more people onboard

Btara Truhandarien — Mon, 17 Sep 2018 22:32:56 +0000

Note: This post is based on fact #3 of the book 'Facts and Fallacies of Software Engineering'"

"Adding people to a late project makes it later"

Back when I was working, I had this one big project that I was assigned to do alone. I was the lead system designer and developer. The project was relatively big for a single person (at least in my team), my best guess estimate back then was that the project can be done in ~4.5 months time (from scratch to finish). But there was a catch, I expected at least two people to come in and help me out with a few things.

After a couple of discussions with my manager, it was decided that one of my colleagues would come in to help me build the frontend early in the project, and another to come in later on to help out for the backend. Let us call the early colleague E, and the one that comes later L.

Fast forward to 3 months later, L started to come in (by this time E was no longer working with me). I had a clear vision of what he ought to do, which was to build one of the components of the system which acts as an intermediary between 2 other components. It was really quite a simple system, what he had to do was create a program that reads a file and splits it up into several smaller files. If any of you are familiar with the bash command split, the program was essentially similar, just that it also had to communicate with the DB a bit.

All in all however, the program is simple enough except, the complexity of a system isn't merely a sum of the complexity of the programs. Which also means that the complexity of a project is not merely the sum of the complexity making those programs.

It took quite a bit of time, and a bit of back and forth between me and L in order for him to get to what I deemed an adequate understanding of how the components work in the system and the design of the system. It also took some time for me to explain the designs and code quality that I want to push through. Basically,

The result is that the new team members are very slow to contribute anything to the project at all

Now to L's credit it wasn't that slow for L to come to understand the overall project design. Nor was his involvement in the project cause the project to overshoot its deadline. Moreover it wasn't that his involvement late into project deteriorate the quality I envisioned for the system. But it does make me wonder, was L actually required to be involved?

Because after L finished his part, I still had to look back to the code he produced and had to modify some things. Some related to code design, some related to minor logic corrections, and others related to testability. Had I just created that component myself (or actually had L joined in sooner to the discussion of the project), would I actually have saved that time taken to fix up that component?

I might have been able to... and if so wouldn't I have finished it sooner than my estimation? Did this make the project "late"? Not even time can tell

[Series] Experiencing Facts and Fallacies of SE - People matter, a lot

Btara Truhandarien — Wed, 12 Sep 2018 07:31:27 +0000

Note: This post is based on fact #1 and fact #2 in the book "Facts and Fallacies of Software Engineering"

"People matter in building software. Tools matter. Techniques also matter. Process, yet again, matters. But head and shoulders above all those other things that matter are people"

"The point of this fact is that they (people) matter a lot"

If you've ever heard of Agile, and you probably have after seeing them in almost every job posting you've seen for software dev/eng, then you may know that the first statement in the agile manifesto is that people > tools and processes.

Now the author of this book challenges us that we don't treat people important enough. So he says - "We treat people like interchangeable cogs on an assembly line".

Which reminds me back in the day when I was working, the company I worked for would hire large number of software devs in order to fill up the few positions left out by employees leaving. A quantity over quality approach. Though at the same time I believed that the company earnestly push their employers to grow.

In a broader consideration I am reflecting on the number of tools and effort put into them for us not to screw up. Linters, npm audit, automated code reviews for just a few examples. How much focus and resource do we then put on the people aspect? What if that same amount of focus and resource was put into people development instead? How about in your working area, do people get enough focus?

That was the management stuff, now let's get down to the more hands-on parts. Consider this: in a project of two, would you prefer to have a skilled colleague working with you, or more tools (relevant to your work) in your arsenal?

My take is that I would prefer having a skilled colleague working with me. There are many reasons I can list here, but the main ones are these:

software is the encoding of human ideas and creativity into machines.
coding is a small part of building software

At the time of this writing the main way to achieve the former (with exceptions perhaps coming soon) is by having a human translate the contents of their brain to an algorithm, and manifest it in code. That is akin to writing a well-written prose, and that requires practiced skill.

The latter is even more important to me than the former. There are many steps to building software, and not to mention all the jumbling and juggling in between those steps. I envision a good software developer to not only be someone well-versed technically, but also in generic aspects; communication, learning, estimating, discussion, planning to name a few. While tools and processes help, I find that an individual's base capability dramatically affects the effectiveness of such enhancers.

But while I talk of how important people are in software development, just as the author said, I "don't know how to identify those 'best' people". But perhaps you do. If so comment below

[Series] Experiencing the facts and fallacies of software engineering - Intro

Btara Truhandarien — Mon, 10 Sep 2018 21:02:54 +0000

A bit over two weeks ago I saw this interesting looking book over at the school bookstore. As a person who believes in professional development for software engineering I took up the book. But of course, as do in most of my attempts to pick up a book (or article), it has been added up to my backlog of to-read list.

So to up the reading game a bit I've decided to make my first few posts on DEV to be about this book and how it fairs against my experience. This way not only will I stay motivated to read the book, but I get to share and converse (hopefully) with others on the subjects presented in the book.

I have no intention to go over through the whole content of the book here, but only those that I feel I have something to say about or have experienced. Hope you will stay tuned on this series (and my first few posts on DEV)