DEV Community: Venkatesh-Prasad Ranganath

Questions to assess culture (fit) in tech

Venkatesh-Prasad Ranganath — Fri, 07 Jun 2024 01:40:34 +0000

Based on my observations of teams, I compiled the following non-exhaustive list of questions to learn about the culture of a work environment.

Do teams have a list of well-defined values and behaviors that allow them to decide and execute mostly independently?
How does the work/development environment support prototyping and experimentation?
How long (or how much effort) does it take to go from idea to deploying a prototype or an alpha version to internal consumers, say, for continuous experimentation and development)?
Do teams conduct retrospectives? If so, for what scenarios and what happens after retrospectives? If not, why not?
How do teams ensure accountability for execution and outcomes? What about accountability for decisions? What about accountability for technical debt?
Would you deem your culture a permission culture or a constraint culture?
What is the basis of decisions in your teams, e.g., opinions, evidence, tenure of the executor, track record of the executor, or benefits from the effort?
What is the decision-making credo in your teams, e.g., skin in the game, no one is hurt, put up or shut up, where the buck stops?
What happens when team X needs feature Q in product P, which team Y owns but cannot build feature Q?
What is the reward/recognition culture, e.g., promo for having a significant impact or promo for executing long-term projects?
Were any projects shelved in the last 6–12months? Why were the projects shelved? Who initiated the shelving?
Who identifies and initiates projects? What is the associated process?
During work hours, how much time do developers spend learning new knowledge that may not be immediately relevant to their current work?

There are no generally right or wrong answers to (all of) these questions. There are different degrees of goodness-of-fit between the provided answers and the expected answers expected to these questions.

Answering these questions can help employers and prospective employees assess whether they are a good fit.

To use these questions, prospective employees should identify the answers to these questions that align with their expectations of a reasonable work environment. Then, they can seek answers to these questions in interviews (remember the “do you have any questions for us?” question :)) or when researching about employers.

Likewise, employers can adapt and adopt these questions in behavioral interviews to assess cultural fit. Before using them, employers should identify the answers that represent their work environment.

Teams and organizations can benefit from regularly revisiting such questions to assess the culture of their work environment.

Of course, the above questions will be useless without honest answers :)

Original post is available here.

Why (not) Containers?

Venkatesh-Prasad Ranganath — Tue, 18 Feb 2020 15:08:12 +0000

Why?

Containers serve as commonly agreed upon deployment unit between Dev teams and Ops teams. This eliminates the possibility of missing artifacts when a Dev team hands over a program to the Ops team for deployment.
Containers allow Dev teams to package any software required by the program to be deployed. This eliminates the need to provide a list of required software to the Ops team when providing the program for deployment.
Containers allow Dev teams to test the deployment of programs independent of the Ops team and the actual deployment environment.
Containers allow Dev teams to test the program as a deployed unit independent of the Ops team and the actual deployment environment.
Containers allow Dev teams to decide how the program uses the available resources without worrying about interference from other programs, e.g., conflicting environment vars, conflicting file locations.
Containers allow Ops teams to manage the deployments by treating deployment units as black boxes (with very few constraints).
Containers allow Dev teams to use a rich set of tools to define applications (= program + required software) and build container images for deployment. [See Cloud Native Landscape]
Containers allow Ops teams to use a rich set of tools to deploy and operate containers. [See Cloud Native Landscape]
Specification (Code) and tools enable automation of tasks associated with packaging, deployment, and operation of containers. This enables automatic detection of issues; possibly before execution of the tasks.

Why not?

Dev teams have to deal with installation nuances associated with software required by their program.
Dev teams have to identify and provide resource requirements along with deployment units, e.g., compute, memory, storage capacity, storage bandwidth.
Ops teams have to ensure optimal resource utilization in the data center while satisfying the resource requirements of the deployed units.
Ops teams have to manage/eliminate interference between containers via the shared host (execution) environment.
Specification/Code and tools enable automation of tasks associated with packaging, deployment, and operation of containers. This amplifies issues due to incorrect specification/code.

How has container technology influenced software development?

The evolution of cloud computing from resource renting to container-driven automation has clearly influenced how we develop and deploy software.

The primary factor driving this influence is the specification/codification of requirements and tasks associated with packaging, deployment, and operation of containers. This factor has reduced ambiguity by the adding rigor in the form of structure/syntax and semantics to the information exchanged between Dev teams and Ops teams. The resulting clarity and precision has expedited the identification and fixing of issues in both process and practice. In turn, this has helped improve the last leg of the software development process.

In short, container technology has served as a tool to help with process management in software development.

While the above opinions are informed, they may be flawed, limited, or might have overlooked some aspects. If so, please point out the flaws, limitations, or overlooked aspects by leaving a comment.

P.S.: I have (ab)used the term “containers” to mean the current container technology and the execution entities. Sorry!

[Originally posted here.]

Implementing View Types in Python

Venkatesh-Prasad Ranganath — Sun, 12 Jan 2020 03:54:50 +0000

In object-oriented languages like Java, C#, or Kotlin, given a type T, an associated view type TView is used to expose a specific view (parts) of an object of type T. This helps hide implementation details.

For example, in the following Kotlin example, Ledger interface is used to provide access to a ledger while hiding the underlying implementation details, i.e., LedgerImpl provides the functionalities of a ledger and it has a process and container members.

interface Ledger {
    fun getValue(i: Int): Int?
}

class LedgerImpl: Ledger {
    val container = HashMap<Int, Int>()

    override fun getValue(i: Int) = container.get(i)

    fun process() {
        // processing
    }
}

fun getLedger(): Ledger {
    val c = LedgerImpl()
    c.process()
    return c as Ledger
}

Can we achieve the same in Python?

Yes, we can mimic the above code structure in Python as follows.

from abc import ABC
from collections import defaultdictclass Ledger(ABC):
    def get_value(self, i: int) -> int:
        passclass _LedgerImpl(Ledger):

    def __init__(self):
        self._container = defaultdict(int)

    def get_value(self, i: int) -> int:
        return self._container[i]    def process(self) -> None:
        ...

def facade() -> Ledger:
    l = _LedgerImpl()
    l.process()
    return l

While _container is marked as private by convention (i.e., the name is prefixed with an underscore), callers of facade can still access _container in the returned value as Python does not enforce access restrictions at runtime. So, the implementation details are not truly hidden.

Can we do better?

(Accidentally) Yes, we can do better. We can use namedtuple support in Python to realize the view type.

from abc import ABC
from collections import defaultdict
from typing import Callable, NamedTuple

class Ledger(NamedTuple):
    get_value: Callable[[int], int]

class _LedgerImpl():
    def __init__(self):
        self._container = defaultdict(int)

    def process(self) -> None:
        ...

    def get_view(self) -> Ledger:
        return Ledger(lambda x: self._container[x])

def facade() -> Ledger:
    l = _LedgerImpl()
    l.process()
    return l.get_view()

With this implementation, unless we thread our way thru the lambda function created in get_view, the implementation details stay truly hidden when compared to the previous Python implementation.

Also, this implementation pattern relies on composition instead of inheritance. While the earlier implementation pattern can be changed to use composition, it still does not truly hide implementation details.

When should we use this pattern?

This pattern is ideal to use when implementation details need to be truly hidden.

And, here’s my yardstick for when should implementation details be truly hidden.

If the client programs of a library/program will respect the access restrictions communicated via conventions, then this pattern is not helpful/required. This is most likely the case when modules within a library or program act as clients of other modules in a library or program. In these situation, simpler realizations of view types (e.g., the first python example) will suffice.

On the other hand, if client programs may take dependence on the implementation of a library/program (e.g., for performance reasons) when the current version of the library/program does not support the capabilities need by the client programs, then this pattern can be helpful to truly hide the implementation.

Note

I stumbled on this pattern during my coding sessions. Since I found it to be interesting and useful, I blogged about it. That said, as with all patterns, use them only when they are required.

(Originally posted here.)

Can I say “I’ll search it up” in technical interviews?

Venkatesh-Prasad Ranganath — Fri, 13 Dec 2019 08:37:36 +0000

Recently, on Linkedin, someone mentioned how a candidate pretty much answered “I’ll search it up” for most questions in a technical interview. I replied “Depending on the context, searching for information is not a bad answer.” The reason for my reply is, given the current pace of the tech sector and the number of technologies and buzzwords that whiz past us daily, searching is a good way to reduce memorization burden; more so, when the shelf life of these new bits of information (specifically, in terms of relevance, effectiveness, and novelty) is often suspect.

That said, the context is very important. For example, is the interview for a senior position or a junior position? Is the question about a technology or a topic/concept? Is the question about basics/fundamentals or nuances? Is the question about the abstracts or details? You get the idea. So, in general, where/how do we draw the line?

Here’s how I draw the line. Being able to search smartly and being knowledgeable to know what to search for are extremely useful skills. So, if the candidate can provide evidence of these skills and demonstrate that she is knowledgeable about the topics of interest, then I’ll accept “I’ll search it up” as a valid answer.

If you are wondering how can candidates provide evidence of these skills, then they should describe example situations where they used these skills along with how they used them to resolve the situation. Specifically, what did they search for, how did they search for it, why did they search for it, where did it lead them, did they lose their way, how did they get back on track, and so on until they arrived at the final resolution. [Now, “I’ll search it up” doesn’t so easy, right? ;) ]

As for how can candidates demonstrate their knowledge about the topics of interest, they should have a good grasp of the fundamentals of the topics of interest — common concepts, common challenges, common constraints, common solutions — and be aware of sources that they could refer to for details. So, grasp of specifics would be a bonus. Also, they should be able build upon and reason using these fundamentals while considering the specific context and constraints provided by the interviewer. This would implicitly require the candidate to be able to reason about different ideas and their combinations. Also, this requires the interviewer to be an active participant in the interview by posing the right questions to unearth the extent of the candidate’s knowledge.

At the end, as long as the interviewer is committed to asking the necessary questions to uncover the relevant information, “I’ll search it up” answer isn’t an issue. That said, as an interviewee, why would you want to make your interviewer work harder? :)

Originally posted on Medium

How would you test for coding skills?

Venkatesh-Prasad Ranganath — Fri, 13 Dec 2019 08:32:44 +0000

First off, by coding skill, I mean the ability to translate an abstract description of a solution into clean, efficient, and working code.

In all of the tech-heavy interviews that I have conducted for junior engineer and research assistant positions, I haven’t explicitly checked for coding skills. Instead, I have done the following.

See if the candidate had CS education/training. If so, then they often will be able to hone their coding skill if they come thru the interview as smart problem solvers with good grasp of fundamentals. Of course, as the interviewer, I have vetted the mentioned CS education/training is a sufficient indicator of the required coding skills.
Examine the candidate’s software project portfolio. If they don’t have CS education, then I have asked for their software project portfolio, spent time examining the portfolio, and discussed the code (i.e., logic, code patterns, code structure, language features, libraries) in the portfolio projects. I have also asked about development practices, problem constraints, and alternative solutions, and if and how these influenced the code and their coding decisions.
Ask the candidate to study our code base. Not everybody has a software project portfolio. Also, neither of the above approaches may provide the required signals, e.g., the candidate hasn’t done Android programming and our code base is all about Android. In such cases, I have shared our code base (of course, being conscious about IP rights) with the candidate and given her ample amount of time to study it along with opportunities to contact my team or me with questions about the code base. Subsequently, I have discussed the code with the candidate to gauge her understanding of both the code and the system at large.

While this approach cannot directly assess coding skills, it can help assess a candidate’s willingness and ability to read and understand code; specifically, other’s code. It can also help assess a candidate’s ability to reason about and have intelligent conversations about existing systems. Candidates with these skills can easily hone their coding skills (provided they are open to learning new things).

Looking back, the above approaches have worked well for me :)

What about take-home coding assignments?

While I have not given take-home coding assignments, I like this practice as it allows candidates to demonstrate their development skills as they would on the job by using commonly used tools and information sources. However, for this to be effective, the interviewer should examine the candidate’s solution. If the solution is good enough, then she should discuss it with the candidate as part of the interview.

On a related note, here are the basic skills that I think are necessary to be a good software engineer.

Originally posted on Medium

What’s with thinking out loud in technical interviews?

Venkatesh-Prasad Ranganath — Fri, 13 Dec 2019 08:28:18 +0000

A common requirement in most white-board coding interviews is a candidate voice out her thoughts as she works thru the problem. The same applies to design interviews as well.

I understand this requirement helps gauge how well a candidate can communicate their thoughts. No doubt this is an an important skill; specifically, in a role that involves lot of interaction.

That said, I think this requirement imposes quite a bit of wastage.

Not all thoughts associated with problem solving are worthy of communication. Do we really want the candidate to voice every thought? (Remember verbalizing thoughts is not the same as communicating thoughts.)
While the ability to be selective about the thoughts to communicate is important, this selection process requires some thinking as well; hence, it shifts the focus away from problem solving. Why force the candidate to shift focus away from problem solving?
If the interview is being conducted in English, then many non-native English speaking candidates may likely not think in English. If so, after forming a thought while solving the problem, such candidates will have to expend some mental effort to translate the previous thought into English before saying it. Again, beyond forcing candidates to shift focus away from problem solving, why put non-native English speaking candidates at disadvantage in terms of time?
The same applies to visual thinkers. Left to their own devices, they could draw up pictures that capture their thoughts and then explain it. Instead, why ask them to explain the pictures as they are drawing?
All candidates are not equal. Due to whatever reasons, some candidates may be more methodical and thorough. This requirement puts unnecessary additional demands on such candidates. Looking at it another way, the requirement asks such candidates to be a bit sloppy in the interest of time. Why demand sloppiness in knowledge-centric domain?
Have you ever tried talking pretty much continuously for one hour? Now, imagine doing it for couple of hours in a row. Why expend energy on unnecessary talking?

Beyond the above limitations, I think the requirement is unrealistic as we seldom operate so while working.

Does your co-worker loudly explain the design/code that she is creating? If so, do you understand her explanation?

In my experience, even when team members meet to discuss an idea, most of the members who lead the discussion early on would have either 1) thought about and worked on the the problem and their solution or 2) experienced similar situations. As for those who contribute later on in such meetings, they do so after understanding and thinking about the solutions as the solutions are being described and discussed.

So, if we never think out loud while working, then why require candidates to think out loud?

This requirement seems to focus on the quantity of communication instead of the quality of communication.

Is there an alternative?

To get the most out of the 45–60 minutes of interview time, we can allow candidates to solve the problem as they would do naturally but without the use of information resources. This will paint a more accurate picture of how candidates operate while designing and coding on the job. To ensure candidates do not get stuck or lost, we can use regular prompting. If we are interested in the process of how a candidate arrived at a solution, then we can state this at the beginning of the interview and set aside time to discuss the solution as a whole and in parts along with the choices made while crafting the solution.

Originally posted on Medium

Spectrum of Data Analysis

Venkatesh-Prasad Ranganath — Fri, 28 Jun 2019 22:47:43 +0000

Descriptive analysis summarizes the data.

Given the daily data about fuel consumed by your car, calculating the average daily fuel consumption of your car would qualify as descriptive analysis that summarizes a feature (e.g., daily fuel consumption) of your car.

Suppose we have the daily data about number of miles traveled by your car, calculating the average daily fuel mileage of your car would also qualify as descriptive analysis. Unlike the determining the average daily fuel mileage, this analysis first combines two features to derive a new feature that further describes/characterizes your car and then summarizes the new feature.

In descriptive analysis, we focus on summarizing either original or derived features of an entity.

Inferential analysis extracts information about source entity of the data.

Continuing the previous example, suppose we also have data about the daily tire pressure of your car. Now, we can try to answer questions such as “does the tire pressure of your car influence the fuel mileage of your car?”, “Is the influence positive or negative?”, and “What is the magnitude of the influence?”

In inferential analysis, we focus on identifying relationships between features of entities.

In terms of time, inferential analysis is all about what happened in the past. So, the goal is to understand past data and answer questions about events that have occurred.

Predictive analysis predicts possible outcomes about the source entity of the data (assuming all things being equal).

Based on the previous year’s data, we know that the average fuel mileage of your car is 35 miles per gallon. Further, let’s assume we have inferred, for each psi drop in your car’s tire pressure from normal (recommended) tire pressure, your car’s fuel mileage drops by 2 miles per gallon. Now, if the tire pressure of your car is 3 psi below normal, then we can predict that you will be able to cover 290 miles with 10 gallons instead of 350 miles (independent of any previous observations of the tire pressure being 3 psi below normal).

Of course, the above prediction hinges on all things being equal. In other words, the prediction can go wrong if either the weather gets way colder or hotter than usual or the road you take is bumpier than usual or the traffic is slower than usual or any other reasons that can affect the prediction but have not been captured in the data or considered in the analysis.

In predictive analysis, assuming all things being equal, we focus on predicting the features of entities based on the inferred relationships between the features of entities. So, in some sense, predictive analysis is an extension of inferential analysis as the results of inference are used for prediction.

In terms of time, predictive analysis is kinda the dual of inferential analysis as it is all about what could have happened or can happen, i.e., both alternative past events that did not occur or possible future events. The goal is to understand past data and answer questions about events that have not occurred.

Prescriptive analysis uses the data to prescribe actions that can lead to desired outcome (assuming all things being equal).

Equipped with the results from the previous predictive analysis and the list of possible actions to increase tire pressure, we can now prescribe an action or a ranked list of actions to get good fuel mileage. So, if you mention that your fuel mileage is below (normal) 35 miles per gallon, then we can ask if the tire pressure is lower than normal? If you reply “yes, it is 24 psi instead of the normal tire pressure of 27 psi”, then we can prescribe that you increase the tire pressure by 3 psi (to 27 psi) to get normal fuel mileage.

In prescriptive analysis, we focus on prescribing actions to manipulate the features of entities to effect changes in features of entities. This aspect of manipulating the entities to effect desired future outcomes is a definitive aspect of prescriptive analysis.

In terms of time, unlike inferential analysis and predictive analysis, prescriptive analysis is all about what can happen in the future. The goal is to understand past data and prescribe actions that can lead to desired future events.

(This is minor edited version of this original post.)

Covariance and Contravariance

Venkatesh-Prasad Ranganath — Sun, 21 Apr 2019 04:59:23 +0000

In the below Kotlin code snippet, Producer class is covariant in type parameter T and Consumer class is contravariant in type parameter T. In other words, T is a covariant type parameter of Producer and T is a covariant type parameter of Consumer. So, what do these statements mean?

To understand the meaning of these statements, let’s consider the allowed behaviors. Copy-n-paste the above code snippet at https://try.kotlinlang.org and run it. You will observe two errors — at lines 13 and 15.

Covariance

The assignment on line 11 is allowed as Producer<Double> is treated as a sub-type of Producer<Number>. This is due to two reasons.

Values of type T can only be retrieved/read from Producer<T> instances because T is used to specify only the values provided by Producer; see the class definition of Producer.
Since Producer<Double> instance is assigned to p1, all values retrieved/read via p1 will be of type Double, a sub-type of the type argument Number of the declared type Produce<Number> of p1. So, the behavior exhibited by the instance assigned to p1 conforms with (is a subset of) the behavior guaranteed by the declared type of p1.

Due to the above sub-typing relation, the assignment on line 13 is not allowed. If it was allowed, p2.read() would return a value of type Number when it should return only values of type Double based on the declared type Producer<Double> of p2.

Contravariance

A similar reasoning explains contravariance.

The assignment on line 17 is allowed as Consumer<Number> is treated as a sub-type of Consumer<Double>. This is due to two reasons.

Values of type T can only be injected/written into Consumer<T> instances because T is used to specify only the values provided to Consumer; see the class definition of Consumer.
Since the type argument Double of the declared type of c2 is a sub-type of Number, all values provided to Consumer<Number> instance assigned to c2 will be a sub-type of type Number. The behavior allowed by the declared type of c2 conforms with (is a subset of) the behavior supported by the instance assigned to c2.

Due to the above sub-typing relation, the assignment on line 15 is not allowed. If it was allowed, c1.write(3) would store a value of type Number in the property (field) c1.e when it should store only values of type Double in c1.e based on the Consumer<Double> instance assigned to c1.

Summary

In short, if type X is a sub-type of type Y and type S<X> can be treated as sub-type of type S<Y>, then S is covariant in T and T is a covariant type parameter of the generic type S<T>.

Similarly, if type X is a sub-type of type Y and S<Y> can be treated as sub-type of type S<X>, then S is contravariant in T and T is a contravariant type parameter of the generic type S<T>.

In both definitions, the key is if S<X> will be treated as sub-type of S<Y> or vice versa, and this is dependent on how the type parameter T of S<T> is used in S; specifically, in the context of input and output of the operations/methods of S.

How to be a Good Reviewer?

Venkatesh-Prasad Ranganath — Sun, 02 Sep 2018 17:21:23 +0000

Independent of the artifact being reviewed (e.g., design doc, code, test, packaging, presentation, book), a good reviewer should do the following:

Identify issues in the artifact (What)
Provide reasons why an issue is an issue (Why)
Suggest how to fix the identified issues (How)

It is not sufficient to merely do 1 and 3. It is necessary to do 2 to

assess the validity of your judgement and
help authors learn and improve.

Here are two examples:

Example 1 (Code)

This field access could lead to a null pointer exception.
The receiver in the field access expression is the object returned from this method call which can return null.
Ensure the receiver object is non-null before accessing the field.

Example 2 (Documentation)

The instruction is asking the user to set up an emulator.
The user may not know how to set up an emulator.
Provide instructions to set up an emulator or explicitly mention the user should be familiar with setting up an emulator.

Donts and Dos for Conversations (and Interactions)

Venkatesh-Prasad Ranganath — Sun, 19 Aug 2018 04:20:49 +0000

Don’t equate modesty with lack of expertise.
Don’t equate chattiness with expertise.
Don’t equate silence with lack of leadership.
Don’t equate loudness with leadership.
Don’t equate directness with rudeness.
Don’t equate questions with insubordination.
Don’t equate questions with disagreement.
Don’t equate politeness with agreement.
Don’t be a time hog.
Don’t wing it. Be prepared.
Be considerate.
Don’t be submissive.
Don’t be domineering.
Don’t jump to conclusion. Instead, seek clarification.
Have a conversation — listen, reason, speak, repeat.
Don’t interrupt when someone is speaking.

That's it for now :)

Static Typing vs Testing == Apples vs Oranges

Venkatesh-Prasad Ranganath — Tue, 31 Jul 2018 10:14:46 +0000

I have heard discussions about why static typing is superior to testing (and vice versa) as the way to lower the number of bugs in systems, and I think such discussions are futile as they are comparing apples and oranges.

Consider the following program fragment (in Python with type hints).

def foo(i: int, j: int) -> bool:
    return i < j

def bar(i: int, j: int) -> bool:
    return i == j

If we consider only the type signatures of these functions, then we have the following.

foo: (int, int) -> bool
bar: (int, int) -> bool

Using only type signatures, we can flag the following invocations as faulty.

foo("1", 3)   # first argument is not of int type
bar(3, [1,3]) # second argument is not of int type

However, type signatures are not sufficient to flag the following invocations as faulty.

if foo(3, 3):
    print("val1 is equal to val2")

if bar(3, 5):
    print("val1 is less than val2")

Now, we might think that these faults would not have occurred if the functions were named as equals and less_than. By renaming, observe that we are not relying on static typing to avoid the faults :)

Nevertheless, let’s go ahead and rename the functions.

def equals(i: int, j: int) -> bool:
    return i < j

def less_than(i: int, j: int) -> bool:
    return i == j

if equals(3, 3):
    print("val1 is equal to val2")

if less_than(3, 5):
    print("val1 is less than val2")

Even now, the code fragment is faulty.

The issue is there are (at least) two kinds of types and we have only specified only one kind of type. For the other kind of type, we are relying on the association between function names and expected function behaviors.

To understand the issue, consider the description of equals function:

Accepts two integer values i and j and returns a boolean value.
Returns true if the inputs are equal; false otherwise.

The first part of the description constrains the values that are valid as input to and output from the function. This description is the value (domain) type of the function, which we specified using type hints (e.g., : int).

The second part of the description constrains the behavior of the function. This kind of description is the behavioral type of the function (one that can be realized in different ways). In the example above, we did not specify this kind of type information.

Static typing as available in most programming languages today are geared towards only specifying value types (and not behavioral types).

If you are still not convinced about behavioral types, then consider relying on just the function signature (List[int]) -> List[int] and picking a function that sorts a given list of integers in ascending order.

What about testing?

Unlike static typing (as it is generally available today), testing is not about value types.

Testing is about specifying and checking behavioral types.

Specifically, a test case captures a specific behavior of a function (e.g., equals(3,3) should evaluate to true, equals(3,5) should evaluate to false), a test suite captures the behavioral type (i.e., a collection of expected behaviors) of a function, and testing checks if an implementation of a function is behaviorally type correct (i.e., function exhibits the expected behaviors).

To draw parallels with static typing, test suites are similar to type hints and testing is similar to type checking.

While testing may seem better than static typing, it is not the case. Unlike static typing, tests are neither succinct nor exhaustive in specifying the possible behaviors of a function under test (in general). This is true even with enhanced testing techniques such as property-based testing. Further, using testing as a way to ensure value type correctness is prohibitive in general.

So, where does this leave us?

Until the day we have static type systems that allow us to easily and succinctly specify both value and behavioral types and use them to check for type correctness, we will need both static typing and testing to lower the number of bugs in systems.

In short, static typing and testing are complementary. And, for now, we need to be able to specify and reason with types and create and execute tests.

Returning to Linux after 10 years

Venkatesh-Prasad Ranganath — Wed, 02 May 2018 00:16:50 +0000

After close to a decade of using Windows and MBP for development, I recently switched back to Linux as my development platform. For this, I chose to run PopOS! on Oryx Pro laptop from System76.

Oryx Pro

In terms of capabilities, Oryx Pro is very impressive. It can house a NVidia GeForce 1060 or 1070, up to 64GB RAM, and a whooping 10TB of storage space!!

While it is not from a big company (e.g., Dell, Lenovo), it is well-built, sleek, and sturdy. In terms of what we have come to expect of form factors of laptops, it is a bit bulky; especially, if one is switching over from MBP. However, it compensates pretty generously in terms of capabilities.

In terms of experience, everything worked seamlessly out of the box. No hiccups or DOA. Customer service and tech support at System76 have been very helpful.

As with life, no experience is without warts :) After few days of using the laptop, I realized there were three major annoyances.

The power port accepts a L-shaped power plug and it is right next to the HDMI port. Hence, when the HDMI port is occupied, the power plug cannot rotate 360 degrees. So, there may be undue pressure on HDMI port and power port due to the interaction between the plugs. I suspect an accidental tug could cause non-trivial damage. A straight power plug can easily solve this problem. [Update: Using a mini-display port located away from the power port solved this problem.]
The integrated Intel GPU is not hooked up to any of the three external display port. This means NVidia GPU is not available as a dedicated compute GPU when hooked to an external monitor, which is when one would want to use a dedicated GPU for compute purpose.
A single battery charge lasts for less than 90 minutes. This is way less compared to that of a Macbook Pro under similar workload when hooked on to an external monitor (driven by NVidia GPU). I wonder if this would have been the case if Intel GPU could drive external monitors. So far, I have been trying various tweaks and they seem to be making some difference. I need to run more test to confirm the observed difference is both sustained and substantial.

Even with the above annoyances, if you are looking for a configurable dev-ready laptop (CPU and GPU) at a reasonable price, then I’d happily recommend Oryx Pro. Just talk to the sales/tech team at System76 and validate your assumptions before ordering your laptop.

Pop OS!

My past experience with Linux is, if you can find and configure appropriate device drivers and applications and get them to play nice with each other, then Linux is developer’s heaven. The finding and configuring was always the pickle. Pleasantly, this does not seem to be the case today.

Oryx Pro came pre-installed with Pop OS!, a Ubuntu 17.10 based distribution. Upon switching on the Oryx Pro, all devices in the laptop were operational and available to be used via software. Fn+F10 toggled the webcam. VLC was able to show the feed from the webcam. USB ports operated at their top speeds without any changes to kernel flags. GPU was recognized with no issue. External HDDs, monitors, keyboards, and trackballs (yes!) were recognized with zero tweaks . I could configure the trackball keys in under 2 minutes. I was able to configure Gnome/X display to span across multiple monitors. Within 3 hours, I had the laptop configured with all of the required software (including downloading them from the web). Yes, I had arrived at my developer heaven :)

Then, I faced two issues.

I started setting up my personal app-specific preferences. Unlike on a PC or or a MBP, I had to manually identify and copy relevant configuration files from a different machine. This took some time for two reasons: a) this was a once-in-a-while kinda task that I was rusty with and it required quite a few web look ups, and b) there were no applications to do migrate my app-specific preferences between Linux and PC/MBP. Since this is an infrequent task, I consider it as a minor convenience.
I started playing with NVidia Settings app to switch between Intel GPU profile and NVidia GPU profile. While the app required me to logout for the switch to take effect, I had to reboot the laptop for the switch to take effect. IMO, this is a major annoyance.

Now, it is possible that I may be doing something wrong here and all that is required is indeed logout and login. Even so, it is still a major inconvenience if one has many apps running at the time of such a switch.

Despite these issues, it was very refreshing to be back on a platform where I can easily install apps from binaries or build apps from sources and get on with my work. [To appreciate this feeling, one should try to install libraries for Python from source on Mac and Windows.]

While I will need to use a PC or a MBP from time to time for specific tasks (cos’ they are easier and better-supported on a PC or a MBP), I am currently a happy to be back on Linux for development.

[Note: The original post appeared here.]

DEV Community: Venkatesh-Prasad Ranganath

Questions to assess culture (fit) in tech

Why (not) Containers?

Why?

Why not?

How has container technology influenced software development?

Implementing View Types in Python

Can we achieve the same in Python?

Can we do better?

When should we use this pattern?

Note

Can I say “I’ll search it up” in technical interviews?

How would you test for coding skills?

What about take-home coding assignments?

What’s with thinking out loud in technical interviews?

Is there an alternative?

Spectrum of Data Analysis

Covariance and Contravariance

Covariance

Contravariance

Summary

Further Reading

How to be a Good Reviewer?

Example 1 (Code)

Example 2 (Documentation)

Donts and Dos for Conversations (and Interactions)

Static Typing vs Testing == Apples vs Oranges

What about testing?

So, where does this leave us?

Returning to Linux after 10 years

Oryx Pro

Pop OS!