Slava I. Maslennikov

Learning

Wed, 19 Mar 2025 00:00:00 +0000

Two months ago, I got laid off. I was ready for this possibility: that’s not what this is about. I knew I was looking at a few months of leisure that I had to intentionally balance with professional and personal growth. After a full day of burning off emotions by splitting firewood, I sat down and set up a plan: making sure that while I take the needed vacation, I’ll keep the momentum.

I set standards: every two weeks, I’ll (1) write a recommendation for a former coworker, (2) write a blog post and publish it on LinkedIn, (3) learn something new in the field and publish the findings, (4) develop a piece of my consulting business, (5) write a non-work-related piece, (6) maintain work-related relationships with in-person meetings. At this point, I kept about half that pace, though I’ve done other productive things for growth, and I missed some of the ones I aimed for. Looking back, that’s fine.

I’m 32, and I never pursued anything I didn’t consider fun - maybe I learned that twenty years ago, by reading Linus Torvalds’ “Just for fun”, or maybe that book just confirmed my mindset. Either way, it takes motivation to do things, and finding or developing that motivation is up to the individual. I’m proud of myself and my ability to keep being productive: writing, engineering, mentoring. I still hold office hours, I still have 1:1s. I’m still doing hands-on work. Most importantly, I’m still learning regularly: the list of drafts of blog posts is only increasing.

I still have room to grow: I haven’t yet found a way to motivate myself to reach for visible learning achievements, such as certifications and degrees. I could never convince myself to learn something for the sake of showing that I know it: learning by doing has been my internalized motto.

This is my system, the trickery I learned over the years for my own quirky brain. I’ve figured out how to hack myself productivity over the years, even during times I’m not working. Find ways to work with yourself: no one can do it for you. Everyone has different ways to do it, some are similar - some are polar opposites. If you know you lack the drive to keep hacking at a subject, like I certainly have, try different ways to get your brain to enjoy it. You’re bound to find one.

Engineer Experience

Sat, 22 Feb 2025 00:00:00 +0000

Are you maximizing a fulfilling environment for your engineers?

If you’re reading this, you probably care about your organization’s engineering culture. I’m available on a full-time and contract basis to help you: shoot me an email!

An engineer’s needs
Further reading
Conclusion

An engineer’s needs

The goal of this blog post is a discussion of retention of talent most crucial to a company’s engineering success and progress. In other words, we’re talking about a long-term game for your engineering department: short-term engineering needs can be satisfied by reversing the pyramid.

Placed on a hierarchy of needs, an engineer’s primary needs are high quality interactions. Not to say that engineer’s paycheck can be fully substituted by kindness: rather, the former can’t replace the latter in a long term proposition.

From another point of view, the higher you look in the pyramid, the more short-term the solutions will become. Lower, more basic offerings, satisfy longer-term needs.

In terms of implementation effort: the smaller the impact, the less effort is necessary to provide it. For example, increasing a paycheck in a toxic team culture is a click of a button, whereas fixing or creating kind engineering culture will take months of effort from multiple levels of leaders, not to mention the recruitment costs.

In the following sections, we’ll break down what each part of the pyramid implies and list some examples.

Communication

Communication is a crucial component of engineer experience: it’s the good and bad of every day that affects people most. This includes interactions with peers, leadership, and the immediate manager. This is also a question of whether managers, peers, and leadership have your back: in client interactions, leadership decisions, even tooling selection. Engineers and their leaders don’t have to like each other or vibe together: but there must be mutual, equal respect and clarity of value. In fact, maintaining a staff of most likeable people is a major bias, as it reduces diversity of thought.

Clear communication between levels is another basic necessity: purpose of every action has to be clear. Translating business needs in clear terms to engineers is the most important ability every people manager should have.

Some of the questions you may ask yourself on this topic include:

Is there a feedback loop with regular surveys? (More on this at the end)
Is there regular communication between the entire engineering team, globally? Is anyone left out?
Are there regular knowledge-sharing sessions? Do all engineers and some leadership participate in them?
Is upper leadership paying attention to the quality of people management skills within people managers? How?

Daily routine

Daily routine refers to three categories:

Ease of engineering
Bureaucracies
Projects

Let’s break these down.

Ease of engineering

This mildly intersects with the upcoming Growth section. It’s crucial for engineering members to be able to perform research and development with ease, to test approaches to problems outside of client or production environments. Engineers should also be motivated to talk about these achievements, and share findings through demos. Unless core intellectual property would be exposed, or business would come to harm, these demos should be public and external: this helps company visibility of high quality engineering culture, and promotes engineer growth and visibility.

Bureaucracies

Bureaucracies are the daily processes that are a business necessity, such as filling out time sheets, submitting and tracking PTO. Additionally, this is the ease of following policies and any other painful but necessary “busy work”. It’s crucial for leadership to facilitate these processes through internal automation as much as possible. Every extra step creates a risk of someone not following the process properly, or at all.

Projects

Hands-on engineering work is the kind that requires periods of unbroken focus time. Every instance of broken focus or workflow is a danger to job satisfaction and progress. Pain points for time management not only include meetings, and queries from coworkers, but also context switching between tasks: both long and short term. Consider the kinds of tasks that one can switch between every few hours, days, weeks. The most ideal project allocations are 100%: every combination of smaller allocations will decrease productivity and toil. Two 50% project allocations don’t add up to 100%: rather, 120%.

You can identify some of your pain points in this section by asking yourself:

How difficult is it for an engineer to create a fresh environment and deploy infrastructure? How long does it take and how many people does she have to talk to?
Do you use engineer-friendly systems? How do you know?
Are regular company processes automated? For those processes that remain manual: how many steps does it take to complete it from beginning to end?
How much documentation is there around policies and onboarding? How much of it is transferred through word of mouth? How realistic is it that every engineer knows all of it and is up-to-date on every change that’s made?
Do engineers get disrupted often? Are internal meetings flexible in timing? Is engineers’ time maximized for heads-down work?
How often are engineers overallocated? Are the same ones consistently doing this? Is the business need clear and obvious?
Do engineers enjoy the work they’re asked to do?
Is there a feedback loop for engineer satisfaction? (More on this at the end)

Growth

When we talk about growth, we’re referring to personal and professional growth an engineer can take home and use in the future. All members of an organization should always be motivated to grow their skills: social, business, and technical. It’s understandable that this may not happen every single moment of a given time period, but when one looks back at a time frame of quarters and years, growth should be obvious to both the leadership and the subject.

For engineers, a big part of growth comes from direct management: through motivation, and clarity of business needs. Immediate managers have to be deeply and closely involved in people management: without this core practice, growth is entirely on the shoulders of their reporting engineers, who may or may not have insight of business needs or direction. The most basic practice of regular 1:1s is too often ignored by managers: while some engineers can find their own path, others cannot, and will be left stagnating. It’s up to the managers to ensure that their reports know exactly where and how to grow, until they develop that skill for themselves.

Growth can be both internally and externally visible: both are necessary. Internal visibility is success in the role: bringing in a difficult client, delivering a knowledge-sharing session, creating novel intellectual property. Examples of externally visible growth are regular blog posts, Github account activity, attendance of conferences and meetups, promotions. Widely shared, external visibility will reach internal circles and benefit the engineer in company growth; the inverse applies. When such bidirectional sharing isn’t possible (for example, when external growth isn’t useful internally, or when security clearances are in effect, preventing sharing of internal successes), maximizing both internal and external visibility are necessary to ensure engineer growth.

Maintaining professional visibility is often overlooked: it is, however, a crucial part of today’s market, used by both internal and external stakeholders to gauge experience and skill set. When an employee and their successes aren’t well-known internally (either because of lack of business impact or a lack of their leadership publicizing it), that marks them as unnecessary. When an engineer’s visibility isn’t obvious externally, it harms their future employment prospects.

All parts of an organization are responsible for engineer growth: Engineer Managers, Upper leadership, IT Support, and Human Resources are all accountable for availability of R&D environments, learning materials, and learning and development funds to facilitate growth.

Some questions around this section are:

Is there a regular feedback loop on the following subjects:
- Immediate people management: effectiveness, growth enablement, regular 1:1s
- Motivation of personal growth
- Clarity of business needs and direction
- (More on this at the end)
Are there clear metrics for measuring People Managers’ performance?
Does upper leadership have clear buy-in for growth, learning, and development? Is it effective?
Are engineers both internally and externally visible? Is there a discrepancy of whose reports are more or less visible? Is there a leadership problem or an individual contributor problem?
Are engineers enabled to be externally visible: do they have Technical Writer support, do they use their personal Github accounts for work?
How difficult is it to spend learning and development funds? Are there boundaries or difficult processes?
How difficult is it to create and use a research-and-development environment?

Compensation

At the top of the pyramid is compensation. When we’re talking about increasing or decreasing it from a set target, that target is market value. While this is the factor simplest for leadership to provide, it’s also the least impactful attribute for an engineer’s long term commitment to the role. Consider an engineer whose other needs in the pyramids are unfulfilled: their communications are lacking or toxic, their day-to-day is full of tedious manual processes and repetitive tasks, they don’t feel like they’re growing skills. This causes stagnation, ignorance, lower quality work, which ideally causes the engineer to leave before they lose too much of themselves.

While this category is least valued, it’s still necessary. In the current state of affairs, it’s expected that engineers discuss their salaries with their peers and senior members of the company, as well as outside it. Resources like Levels.FYI, H1B Salary Database, GlassDoor are available for everyone to find their approximate value in the market. Your most valuable engineers (confident, skillful, with excellent business acumen) tend to be the best at ensuring their growth and at interviewing, putting them the best position to leave.

There must always be a clear reason for differences in compensation: market turmoil is not a good reason to pay some of your engineers more than others. If a company has the cash flow to hire new engineers to perform more work, it has the cash flow to increase existing salaries. Note that such fluctuations can be covered with bonuses or stock offerings rather than base pay, and extra technical needs can be filled with contractors rather than FTEs (Full Time Engineers). There are benefits and losses to all parts of this equation.

Some questions you should ask yourself are:

What are engineers of comparable levels earning at different companies, including base, bonus, and stock? What could a given engineer, with their skill level and social skills, be earning elsewhere?
Do your people managers have visibility and control of their reports’ salaries?
Does everyone in your organization have a clear understanding of the reason for disparity in their compensation, whether low or high?
Do engineers’ raises have clear parity with merit?

Feedback process

You’ll notice how often I’ve used the word feedback in this proposal. Three of the four most important parts of the pyramid are largely supported by a constant feedback loop:

Solicit feedback through anonymous survey.
Provide the findings to upper leadership, through Human Resources for any necessary filtering or rewording to ensure leaders can’t retaliate against their reports.
Discuss the findings with direct leaders: positive feedback should be public, negative feedback should have engagement and follow-through.
Discuss all filtered feedback with the engineers: present improvement plans, provide regular updates.
Repeat regularly, depending on severity.

Finally, everything in this proposal depends on all levels of the company hierarchy: Engineers, People Managers, Upper Leadership. All three groups, all individuals have to be on-board.

DevEx

This isn’t DevEx (Developer Experience): a discipline of maximizing engineer performance through quality tooling, automations, and Technical Operations support. This is an expansion on the DevEx philosophy focusing on what leaders and engineers can do to have the best experience working in an engineering department.

Conclusion

If you read this far, you probably care about your organization’s engineering culture. I’m available on a full-time and contract basis to help you: shoot me an email!

READABLE documentation

Mon, 10 Feb 2025 00:00:00 +0000

Documentation is only as powerful as its reader. Bring your writing closer to your audience with a few extra steps. Make it READABLE: Readable, Enjoyable, Accessible, Documentation is Always Better than Lazy Entertainment. Ok, yeah, that’s silly, but more about that later.

Individual need
Use your silly voice
- How to come up with an acronym
Simple structure and flow
Automate instead of document

Individual need

How does the documented process affect the reader as a person? What role do they play in it? Make sure these are immediately outlined in the first couple of sections.

When you document a process for an engineer, why should they care? No matter the business importance, without motivation, tasks will be routinely delayed or ignored.

Example: submitting time sheets in a consulting business. If it’s not done every Friday or Monday, accuracy will inevitably drop - and you can forget about any useful task notes. This isn’t immediately important for an engineer: they aren’t involved in business metrics, or billing, or the managerial tasks of explaining to the client what their hours have been spent on. What an engineer does care about, though, is their bonus, utilization, and future project assignments. A better explanation is: time sheets give the business visibility into past utilization and availability for future projects. Allocation alone is a poor indicator of time use.

Use your silly voice

People like humour. That’s why for every piece of process or documentation I write in a professional setting, I add a touch of fun:

In the top-right corner, you’ll generally see a haiku. It doesn’t have to be good, it doesn’t have to make sense, it doesn’t have to take long: it takes the edge off the daily routine. If I was of a different generation, I’d probably use a meme instead: that’s just another approach to the same problem; just make sure you’re not overdoing it.
When I start initiatives, I spend the first 30 minutes by generating:
1. An acronym for it. I’d quote some, but they’re past employers’ property now. I will, however, outline my process for coming up with them in the following section.
2. A logo. I build this in Pixlr because it’s free and fast. Make a background shape, add some relevant transparent clipart you found on Google Images, change some colours, and you’re good to go!

How to come up with an acronym

It’s simple:

Brainstorm a list of all words relevant to your initiative that you can think of.
Can you use any of the words in the list as an acronym? If you’re close on one, spread it out vertically letter by letter, and fill it out. Try to make a sensible sentence.

Hints:

Predictable words (or really, any words you choose) may not be included in the acronym. Or include some and skip others, depending on your own imposed difficulty level.
You may use multiple first letters from a given word.
Use and abuse ChatGPT for some of the brainstorming. You can also try it for the entire process, but as of writing it provides invalid results most of the time.

As an example, this took me ten minutes to come up with:

Simple structure and flow

Make sure your writing is easy to follow:

Are you providing examples?
Are you using bullet points instead of large paragraphs?
Do you prioritize most frequently-used information on top?
Do you have a table of contents that shows flow?
- Google Docs and Confluence have built-in generators for TOCs. For Markdown, I use a lightly modified version of markdown-toc
When generating documentation with AI, are you pre-feeding it your voice by submitting past writings?

Automate instead of document

Lastly, instead of going through the trouble of documenting a process well, consider two forms of automation:

Do-nothing code is an excellent alternative to some process documentation.
Zapier is a great way to automate some or all steps of certain processes, but functionality is is very limited. I was able to automate numerous manual tasks through a mixed use of Zapier and home-brewn microservices at my last company.
Simplification: time sheets at my previous company were too much effort to automate, but I did write a time calculator that pulled meetings data out of Google Calendar and spit out the time use for the previous week.

Yerevan

Fri, 27 May 2022 00:00:00 +0000

I lived in Yerevan for the month of November 2021. These are my findings and notes.

Overall
Yerevan
Lake Sevan
- At Semo
Dilijan
Garni
- Garni Temple

Overall

Locals learn Armenian as the first language, Russian as the second and English as the third. In the city, it’s easy to get by with English but folks will take advantage of those who don’t know local pricing and culture. Speaking Russian helps and certainly expands the tourism horizon to most of Armenia. Unless you’re good at communicating through body language, that is.

People in this country are extremely accepting of tourists from really anywhere: however, the LGBT community is just barely tolerated. Religion is widespread.

Folks drink and smoke a bit more than in the States. Currently it’s still allowed to smoke in restaurants and bars, but there are usually separate sections for such activities.

There’s a constant war with Azerbaijan and Turkey. Things have been relatively safe, but locals are in perpetual mourning over lost lives and lands over the years. Being cognizant of these facts as a visitor is invaluable.

Yerevan

The Alexander Hotel

While I didn’t stay here, I did come in for meals and tea while working. Quiet, simple, high-quality.

Livingston

Fancy shmancy restaurant at the top of a building. Excellent food, live music, dancing. Bring cigars.

Malkhas Jazz Club

Didn’t make it here, but heard amazing things about it.

American Hot Wings

Excellent hot wings and burgers in a modern atmosphere.

Beatles Pub

Divey bar with a piano, delightful atmosphere and good beer.

In Vino

A great place to come in, buy a bottle of wine off the shelf, munch on some cheese plates.

Pahest33

A bar/club hidden under a park in the city. Seek out the signs with its name and head downstairs for excellent food and drinks!

A random Jazz club

The name of this Jazz club is unfortunately lost in my notes, but it’s thoroughly enjoyable. There’s usually a cover when bands play, drinks are good and there’s food available as well.

Wine Republic

Great restaurant with a large wine selection.

Paulaner

Lots of beer: imported and local.

Park Cafe

Beer, drinks, food - pretty good and standard.

Yerevan Tavern

Beautiful setting, delicious soups, pretty good meats, beer, drinks.

Jazzve

A chain of cafes - perfect for lunch or tea and desserts.

Lake Sevan

At Semo

Delightful restaurant, make sure you try the fish soups!

Dilijan

Lake Parz

Lake with a bunch of activities like ziplining. Excellent personnel, and there’s also a restaurant with a wood stove!

Restaurant Ureni

Excellent restaurant where your party is seated in an individual wood building heated by a wood stove.

Haghartsin Monastery

A cluster of old old monasteries. Beautiful to walk around and explore.

Garni

Garni Temple and basalt formations

An incredible temple from 1st/2nd century AD on top of a cliff. Below is an amazing crack in the Earth with beautiful basalt formations.

Interviewing engineers

Thu, 17 Mar 2022 00:00:00 +0000

This post was originally published on the SADA Engineering Blog.

In my numerous job hops over the last few years I’ve experienced all ranges and types of interviewing. At SADA, we’ve been able to build out interview scaffolding that has proven to be effective for both parties—the interviewers and the candidate. This post is a rough outline of how we move engineering candidates from recruiting to hiring. There shouldn’t be any big secrets here. This guide will help you know what to expect, but you certainly want to be prepared with the right mix of skills and experience, as well.

Please note that interviews for leadership candidates are out of scope for this post.

General approach
Rounds
Ending a round early
Take-home tests
The interview rounds
Wrapping it up
Personal horror stories
- Reading obscure bash

General approach

Some of the primary goals of interviewing are to determine whether:

The leveling is correct.
Current employees would like to work with this engineer.

Keeping these assumptions in mind will help you to answer the question “what should I ask this engineer to make the interview effective?”

Rounds

After a short recruiter call, we use two to three interview rounds, consisting of about one hour each. These rounds focus on three areas:

Technical
Behavioral
Leadership

These should be fairly self-explanatory, but we’ll look at each of these rounds in more detail later on. The leadership round is used only for higher-level positions.

In each round:

An internal Slack group is set up to coordinate the interviewer’s efforts.
The last ten-to-fifteen minutes are reserved for the candidate to ask their own questions.
After the round, we congregate internally to align on our thoughts and compare notes.

It’s important to keep in mind that structuring the interview process into these rounds helps to avoid the overlap of question themes. We try to keep the technical round technical, and so on. Additional commentary is always welcome in the scorecard, of course.

Ending a round early

We’re all busy, but we all have feelings. If the basic knowledge or expertise is quickly ruled out, the panel may coordinate an early ending to the interview. This usually cuts the meeting time in half. The candidate is still prompted to ask their questions of the panel and isn’t directly notified of the outcome of the interview.

On the other hand, if the candidate excels and is an obvious fit, we may also end the meeting early. This is rare, as instead of ending early, we generally try to ask harder questions to see if the candidate is suitable for a higher-level position.

Take-home tests

We’ve tried them, but we don’t do them. I have mixed feelings about their efficacy but did build out some concepts.

The interview rounds

Next, let’s take a look at the interview rounds. Usually they follow this same sequence, although sometimes scheduling demands might require them to happen in a different order than shown here.

Technical round

In this meeting, the panel includes two engineers and one manager. The manager is there to direct the flow and provide general oversight, while the engineers take turns asking technical questions. The interviewing engineers generally don’t require any special preparation to take part in this panel, aside from a list of generic areas of expertise we seek. We don’t do whiteboarding, but we may present a diagram to facilitate specific queries. For example, a networking diagram might be used for asking CIDR math and routing questions in a given network.

The questions asked of the candidate are never the same, but the interviewing engineers will go in-depth on several technologies and ask questions or prompt for conversation lines that could only be answered by someone experienced in the topic at hand. For example, if a candidate says they know Terraform, they may be asked about locals, variables, count, looping techniques, state, and state locking. It’s easy to determine the level of a candidate’s expertise (basic, intermediate, or expert) by their depth of knowledge of technologies that we use on a regular basis. On a more general level, we may use a specific client scenario and ask how the candidate would proceed within that context.

Behavioural round

The key of this round is to query the candidate on their soft skills. Specifically, we aim to verify these abilities:

Engagement
Communication
Interest, direction, and motivation
Working in a team
Culture fit
Relocation fit (if applicable)

I like to summarize this in three sentences:

Can you work with other engineers?
Are you motivated to grow and learn over time?
Are you friendly, overall?

Leadership round

Lastly, a mix of Directors, Department Heads, and sometimes the COO will congregate to vet the decision to hire a higher-level engineer. This round is generally focused around self-selling and soft skills. The necessity of this round is driven by the role for which we are hiring and it may not occur for all positions.

Wrapping it up

That about covers it. The process described here is generalized and there might be fewer (or more) interview rounds. Naturally, the details will vary depending on the position. Hopefully, this overview provides some insight into our interviewing process and what you can expect. If you would like to see this process in action, do consider our open positions—we’re hiring!

Personal horror stories

As I remember them, I’ll add my own experiences of interviewing at other companies.

Reading obscure bash

Scenario: I was presented three five-line bash scripts with various relatively obscure bash uses and was questioned of their output.

Issue: This isn’t a real-world scenario: you always have access to Google, man pages and most importantly the ability to test things out in a local environment. Testing for remembering obscure syntax is closer to a high school history exam than an tech interview.

Remediation: Ask a problem and how you’d solve it in bash. If it doesn’t suffice, ask how you could improve it. Talk about tools available, both native to bash and external ones. Brainstorm with the candidate, assess how they think: not how they remember syntax.

Caveats of buying a house

Tue, 25 May 2021 00:00:00 +0000

Buying a house for the first time, I ran into obstacles that I feel my agent should’ve voiced. Hindsight is 20/20, so next time I’ll be in better shoes - doesn’t mean these things should remain secret to the world.

I’m obviously not a lawyer so please don’t pretend I’m giving an internet rando legal advice.

Overall process
House searching
Loans
Closing procedures

Overall process

Find an agent (or hire an attorney for filing paperwork and pocket the 3%)
Get pre-qualified by a bank
Find a house
Submit an offer
Get your loan finalized
Bank performs an appraisal
Perform a general inspection
Perform a pest inspection
Finally, close on the house and move in!

House searching

Ideally, the agent does the legwork here, specifically:

Finding compatible houses to look at
Setting up appointments for viewings

The first thing to figure out is actually the loan - because this will determine some requirements for your purchase. Some sellers will only accept specific loans: usually the property listing will show this information. Also, look out for as-is sales, as banks won’t usually give a loan for these properties. So, in general, watch out for:

Types of loans accepted
As-is sales

Agents

There are generally two agents involved: seller’s agent and buyer’s agent. Each earns up to 3% of the sale price, which comes out of the seller’s funds.

Optionally, the buyer can do all the work themselves by hiring an attorney for filing the offer and other paperwork - that way the 3% comes back to the buyer in closing (minus attorney fees, naturally. Word on the street is that this generally costs a few hundred bucks).

Manufactured homes

…are a little more of a pain than stick-built ones:

The interest rate on these is higher than stick-built
These don’t appreciate in value as well as stick-built homes
Finding homeowner’s insurance is more difficult and the payments are higher

So, it’s generally easier to avoid manufactured and mobile homes. Other than these issues, though, it’s fine: you can barely tell modern manufactured homes from stick-built ones. Ours is an ‘84 double-wide model (so, not modern) but I’m still happy with it.

Submitting an offer

An offer is a legal document that includes the following:

Offer amount: can be higher or lower than asking price, depending on the market
Various information about the buyer: name, job, address - why the seller should know this is beyond me (by others’ accounts, this is optional, so who knows)
Earnest money: an amount you’re willing to give to the seller right away, which you lose (all or some of it) if you retract the offer later
Contingencies which you can waive, or not - these include Appraisals, Inspections, the Interest rate. This basically means the offer is contingent on all these things working out as they “should.” If the buyer is dependent on a loan for the purchase, some of these they have no choice on: for example, the Appraisal.

Overall it’s not a good idea to submit offers on every house you see, because if it’s accepted and the buyer retracts it, the earnest money is lost. By others’ accounts, this is exactly the logic in some places: the key then is to rescind the offer before seller’s acceptance of it.

Offers are finicky, there are minimal requirements, but in a seller’s market it may be difficult to get an offer accepted. That’s why often buyers will incentivize sellers to accept their offer by removing contingencies, offering more than asking price, submitting a personal letter, promising a faster closing time, or even paying in cash. One of my offers was refused just because the seller was a veteran and they preferred to accept an offer of another veteran - it can be as simple as that.

Loans

Pre-qualification

This only means that the bank will likely give you the loan. This is a necessary step to submit an offer for a house. This does not include the bank telling you what terms your loan will be on: this you must request specifically, and it takes time.

Ideally by the time you submit an offer for a house, you will have solidified your relationship with a bank. To do that, don’t just get a pre-qualification, but also ensure you know the following metrics:

The interest rate the loan is subject to
The closing costs that your bank controls
Any points applied to your rate

When I submitted an offer, I found out that the rate I was promised included a point, so I went out to frantically look for another bank with better terms. In the end, I did have success here but it was a stressful time because retracting an offer is apparently a dangerous game.

Loan terms

There are a few key terms in a loan:

Principal is the amount of the loan you’re taking out.
The interest rate is the actual rate that your principal is subject to.
Points are a way to increase or decrease your interest rate at the time of closing. Points cost upfront money, so if you will save on interest overall, it might make sense. You can also have negative points, in which case your interest rate is higher, but you get credited cash upfront.
Closing costs are the immediate costs of various services necessary to close the deal: some of these the buyer can pick, while others the seller picks. Most of the closing costs are paid for by the buyer, but some - by the seller.
APR is the adjusted interest rate that includes closing costs. It’s arguably less important than the interest rate, since it’s largely unknown until the deal is closed because closing costs tend to adjust throughout the process.
Loan insurance is generally applied when the buyer has less than 20% stake in the property. One can request to remove it once about 20% of the principal is paid off.

Closing funds sources

Whatever down payment you provide has to be proven to be legal: in my case, I was required to submit three months of statements from bank accounts that will be my sources for the final wiring transactions. Any transfers into the account have to be validated: any gifted money must be proven by a gift letter, signed by the source. Statements of the source bank account are also required. In the end, this is all done to prove that the money isn’t being laundered.

Homeowner’s insurance

This is generally pretty cheap, and the bank does require it for the loan, though you can pick the company and amounts. The total coverage has to be at least for the amount of the loan, aside from that the buyer can change things around.

This is more difficult to find for a manufactured home, and more expensive. I was able to secure a decent policy through AmFam. Beware of home warranties for they’re not the same thing!

Closing procedures

Oh, “closing” is the 7 to 60 day (depending on the bank and how fast they move) process of the buyer actually paying the seller and taking possession of the property.

Appraisal

To avoid another 2008, the banks send out a supposedly independent appraiser to make sure the property is worth the offered price. If the appraisal comes back lower than the offered price, the buyer will need to throw in cash for the delta (or, if it was a contingency in the offer - they can rescind the offer).

General inspection

This is something the buyer pays for upfront - or, the seller may have already performed an inspection and is then required to provide its results (at least in WA) to buyers. The bank doesn’t care about this, but the buyer should. A guy shows up, walks around for a couple hours checking what’s broken or unmaintained - while you rudely drink beer in front of him. Cheap and worth it: during my inspection, a leaky water pipe dripping onto electrical was found. At the risk of the seller dropping your offer outright (because they can), you can ask them to fix stuff you find. Generally, only big issues should be requested though.

If you’re handyman enough, I guess you could do this yourself.

Pest inspection

Depending on property location, different termites are out and about. In CA, there are all different kinds, while in WA there are only subterranean termites. Still, none are fun. Pest inspections are often free, so get it done if possible. In my case, I neglected to for various reasons, and a week after move-in, I got termites coming in through the vents. The balance of speedy closure with a good purchase is fickle!

One year later

A year after your loan starts, expect that your payment may change. In my case, the escrow increased due to property taxes, so my monthly payment shot up by 115$.

Moscow

Fri, 26 Mar 2021 00:00:00 +0000

I was born and lived in Moscow until 2006, when I was in my early teens. I wasn’t able to make it back until 2021, fifteen years later. The city managed to stay the same in all regards important to me, while vastly improving infrastructure. Moscow remains my absolute favourite city.

Generics
Restaurants
Stores
- НИКС (NIX)

Generics

Getting around

There is absolutely no trouble getting around the city on foot. The Metro is vast; its pass system now includes above-ground transport. An unlimited transit pass for one month is currently 2700RUB (~33USD). Getting into the city from the airport involves taking an AeroExpress at a whopping 400RUB (~5$).

The Metro system has nearly doubled in the last fifteen years. Its new cars have USB ports by the seats, digital screens of upcoming stops - though, I was happy to find out that the old cars are still in rotation. Stations are announced vocally, in both Russian and English.

I’m not a lawyer, so don’t take this as any kind of legal advice, but as I understand, one can drive with an American Driver’s License. It took me an embarrassing amount of time to find the legal stipulations around international driver’s licenses: these are defined in Article 25, parts 12 through 18 of Russian Federal Law. As long as the license has the name in cyrillic or latin characters, it should suffice - otherwise a notarized translation is necessary (I got mine translated just in case, this cost 900RUB (~10USD) and took Perevod.ru just a few hours to complete).

Payments

Yes, Russian automated registers require a PIN for credit cards. It takes banks seven to ten days to mail you the PIN and, at least in my case with Citi and Chase, there doesn’t seem to be a way around it. However, if you pay in-person with a cashier, no PIN is necessary.

Ozon is the Russian version of Amazon. Within the city, one can often get 90-minute or same-day delivery on select items. That said, it keeps declining my US credit cards, I’m not yet certain why.

Tips of ten percent are expected for the usual services like waiting, moving furniture, etc.

Cell phone and bank accounts

In Russia, one may not purchase a cell phone plan or open a bank account without showing a Russian internal passport or an international passport of another country - something you wouldn’t have, for example, if you’re a Russian citizen without another citizenship who left the country before turning fourteen and hasn’t come back in fifteen years. Very odd situation (that does get resolved, but not quickly) for some.

Restaurants

Хинкальная 777 (Khinkalnaya 777)

Absolutely fantastic Georgian cuisine.

Хинкальная (Khinkalnaya

Another great Georgian place.

Good food and beer to have on Arbat st.

Ресторан Краснодар (Krasnodar)

Great food, smaller beer selection, quiet and relatively upscale.

Трамвай (Tramvay)

Excellent food - especially the duck, chicken and tartar. The lamb was underwhelming, however.

Howard Loves Craft

Lots of good craft beer, tasty burgers, younger crowd and live music.

Larionov

Just had a beer here: quiet atmosphere, spacious and clean.

Му-Му (Mu-mu)

A chain of Russian fast-food restaurants. Good, healthy food, beer, juices at a minimal price.

Зелёная Дверь (Green Door)

A simple anti-cafe: you pay either for an unlimited amount of time or by the minute (400RUB or 3RUB/min, respectively) and get free tea, coffee, candy, various other sweets and access to board games. Good place to work from: though probably not the best for remote meetings. There’s also a shower available.

Stores

НИКС (NIX)

A net of computer parts stores with many locations to pick up orders from.

Excellent Code

Tue, 16 Mar 2021 00:00:00 +0000

This post was cross-published on the SADA Engineering Blog.

Once upon a time, as I was starting at NordstromRack.com | Hautelook as a Platform Engineer, I found myself impressed with a requirement stated in our Employee Handbook: a requirement of generating Excellent Code. I haven’t been able to confirm its existence in the current handbook (not that I tried very hard), nor did I find a similar description of it elsewhere. However, I do feel like I keep seeing references to it in Hacker News literature: at this point I can no longer confirm that it wasn’t a hallucination all along; “The smell of dry blood, dirty foot prints circling each other, that aroma of old sweat like fried chicken, the feel of a floor still warm the fight the night before”.

What follows is my attempt of recreating the tenets of Excellent Code, five years later.

Design and planning
Compiled, interpreted and scripting languages
Documentation
Code versioning
Local development environment
Automation
Further reading
Annotations

While relatively opinionated, it is intended as a general overview for more junior developers that are new to the field. I won’t be going into the code itself, so much as the way we think about and plan our code to ensure that we have a clean, effective deployment with fewer hassles.

While imperative to effective project planning, concepts such as database engine, underlying compute infrastructure, and several other global topics are not in scope for this article.

Design and planning

The larger the task at hand, the higher the risk of time loss due to lack of planning. Consequently, the larger the task, the more planning is required before actual programming work begins. The largest tasks should be planned, designed, and peer reviewed before any code is written. Even some small types of artifacts, such as architecture plans, design plans and diagrams should all be developed in this process.

Compiled, interpreted and scripting languages

Before getting to work on any programming task, give some thought to deciding which language is most appropriate.

Ask yourself:

What libraries, SDKs, and APIs are necessary?
What languages do they support directly?
How complex is the task?
What kind of logic is necessary?
What is the risk associated with logic failures of this codebase?
What kind of error handling is expected?
Is the code expected to run in containers?
What limitations and implications can be expected with your language choice there?
What automation is expected to manage this codebase, its testing, and deployment?
How does your language preference support it?
What language is the most accessible for the rest of your team to manage?

While lightweight shell scripts can manage simple tasks, they tend to be brittle and difficult to unit-test properly. On the other hand, highly critical production elements with a high risk of loss due to malfunction may deserve stricter compiled languages, with specific tests against undefined behaviors and other dangerous circumstances.

For example, I once wrote some code for a Raspberry Pi cat litter box controller in C. Initially, I wanted to write it in Golang, but the most popular Golang GPIO library for Raspberry PI had a bug with potential to brick the device. Since WiringPi did not have such a bug while having a larger community, I went with C. This shows the importance of researching design constraints before beginning any work.

Documentation

Aim to write self-documenting, self-descriptive code. When adding inline commentary, describe the why of your code, not the what. This is important, as it allows someone coming along afterwards to understand the thought process. When making future changes or fixes, understanding why decisions were made can save a lot of time and investigation. As for technical documentation, design choices, and overall code structure — keep it next to the code, in the repository. Ideally (though not always) in a single README.md file. You can also link directly to previously approved external technical design documents.

It’s always easier to use Ctrl-F in a web browser on a single page than having to use a local search function or that of a Git repository host. Things like collapsible sections, tables of contents, and inline diagrams help keep documentation clean and accessible.

Code versioning

Absolutely all code should be hosted under version control, such as Git. Without this, there is no way of tracking changes, reverting problematic commits, or even effectively tracking versions.

Whether you use others’ Git refs or not, it’s important to realize their potential and necessity. When you show iterative progress, you not only allow for reverting of specific changes in time, but also provide developers (yourself included) documentation on the change.

Lastly, a largely overlooked engineering practice is Git commit signing, which verifies that it is actually you that is committing the code. Without this, it’s trivial to impersonate Git commits on many popular platforms.

Local development environment

As difficult as on-boarding usually is, the lack of a push-button local development environment in a code base makes it even harder. Make sure it’s easy to deploy the entire application locally:

Use Vagrant, Docker Compose, or another platform with similar ease of use.
Support dummy endpoints, databases, Cloud APIs, and similar external entities.
Provide sample database dumps to develop against.
Document the happy path for the local development environment suite.

Automation

It’s crucial to develop automation around a codebase of any size. This helps not only in abolishment of manual tasks, but can also be referenced during on-boarding for understanding a specific application’s life cycle. Additionally, it also benefits applications with rare changes, for the same reasons.

A generic pipeline around any codebase includes:

Testing: Unit tests, smoke tests, basically anything that can be done quickly to immediately show the engineer any issues that may have been introduced.
Deployment to a staging environment: This is where the application is thoroughly tested in interactions with other applications; also known as end-to-end testing.
Manual deployment to a production environment: This is generally a push-button deployment to a customer-facing environment.

Conclusion

There you have it. As we talked about earlier, this presents you with some core principles and practices that, if used thoughtfully and consistently, will save considerable time and effort, resulting in reduced frustration and more efficient deployments.

Fairness and Law Enforcement

Wed, 02 Sep 2020 00:00:00 +0000

Law enforcement happens to be a hot subject in this time, but ideas I mention here are older than dirt. While it’s fairly obvious that race affects the subject’s perception in the eyes of a police officer, I think there’s merit for a deeper discussion on the subject.

Police officers have become primary judges. Every interaction with a law enforcement agent allows for their lenience: they’re trained judges of character, and generally act according to necessity. This discretion, however, isn’t always beneficial: it allows for a difference in punishment as the officer chooses. When an officer pulls a driver over for a speeding violation, they may choose from a range of recourses, including an unofficial warning, an infraction or further investigation at the scene or at the station. This judgement is usually based on subject’s nervousness, appearance, state of mind. Other, less favourable factors, however include race, skin colour, apparent wealth, nationality, sex. Officer’s personal pet peeves, annoyances and hunches as well as their mood of the day can also affect the course of action. This is the first stage of judgement one goes through, before stepping in front of an actual judge in a courtroom. Even there, however, all the above nitpicks affect the outcome: the judges are said to trust a police officer more than the defendant, public defendants are underfunded and can’t realistically represent every person in a quality manner.

I question the fairness of this process, as it allows for unequal justice both in the streets and in the courtroom: there tends to be prejudice against minorities, while friends and police officers get away with as much as murder, as the recent events show. It’s said that police officers run on departmental quotas and there’s no question of the value of revenue from fines: the beneficiaries seem to usually be the county and the police themselves.

Many years ago, I realized why it is that all cars produced in the States don’t have built-in governors even though every state has its speed limits: one is allowed to break the law as long as it’s unseen. One can speed, do drugs, drink and drive - as long as no one notices, because if no one notices, one isn’t really harmful to society. But it’s the simpler laws, - broken license plate lights, relatively low speed limits¹, - that catch a select group of people with more violations than initially seen: poorer minorities.

One solution is execution of laws to the dot, equally against every perpetrator. If an officer spots a car exceeding the speed limit by any amount, the officer would be required to submit an infraction: they won’t sit around waiting for a cheaper car to pass with a potential for more violations. This will be absurd, the police officers will be forced to focus on useless acts. The only recourse will be to amend the law: raise the speed limit to a sensible value, allow for homelessness or spend more revenue on homeless shelters. The laws that are broken daily by most members of society will be removed to allow enforcement of more important ones at an equal rate.

Additionally, there would no longer be room to haggle with law enforcement. No longer is it possible to “get out of a ticket” at a traffic stop. There’s no reason for a police officer to be rude: he’s doing his job, giving tickets as required by the law. If both parties fully realize the inevitability of a fine or arrest, clashes should decrease. A strict execution of current laws would reduce the superset of unnecessary laws.

Don’t get me wrong, this could never work: beside the logistical impossibility of forcing law enforcement officers to act the same for every detention, they could simply avoid areas of these low-paying infractions. None of this idea can possibly work or have the suggested outcome, but one can dream.

A counter opinion by Lev G., which I have not yet formed a response to

If I understand correctly, this work posits that removing the human factor from legal enforcement would strip the capacity for racial and other biases from peace officers’ line of work. Not only would this ensure officers don’t have personal leeway in deciding how law is enforced, but it would provide transparency for the legislature to pass laws more reasonable and equitable for all. The way I see it, this is a call for a higher objectivity in social governance; removing the subjective factors of human discretion as much as possible. There is a logical appeal to this reasoning, but I believe it does not consider a malignant relationship between objectivity and power. While a stricter surveillance of peace officers would address personal biases in law enforcement, it may simultaneously empower systemic racism within the laws themselves.

If there was an omnipotent legislator who made ideal laws for all, as was conceived in Plato’s Utopia, the call for more strict application of law would certainly serve the higher good. But there is no such being, it is human relations all the way to the top. Focusing only on transgressions of the peace officers presents a mirage that above them is something besides people using force upon their discretion for some nebulous greater good. This mirage is called objectivity - that there is human relations and hard knowledge. It encourages one to strip themselves of the human factors and devote themselves to that which they believe is objective. I believe this is but a transference of power from one subjective sphere to another. Likewise, committing to strict application of law without addressing the biases within laws themselves would address one side of the problem while exacerbating another.

I’m no opponent of requirements for safe roads and its users: brake lights should work, speeding is bad, etc. My main point here is full enforcement of all laws when presented with all subjects. There should be no room for decision: a broken light is an automatic citation; but maybe that doesn’t mean one has to be pulled over and scrutinized for further violations: police cars already have plenty of technology to take a picture of a car, its light out, its license plate - why not mail the fix-it ticket to their home address? ↩

San Diego

Fri, 17 Jul 2020 00:00:00 +0000

I spent too much time in San Diego as a teenager. The downside of that was being a teenager, though the upside was finding all the inconspicuous sights.

A buddy of mine moved there, so here’s a list of places to see, things to do.

Breweries & Bars
Restaurants
Shops
Beaches
- Cardiff Beach
- Black’s Beach
Sights

Breweries & Bars

The Dog

Fantastic hole-in-the-wall pub with free pool. The manager is a great friend of mine - tip him well!

Aero Club Bar

Historic bar near the San Diego airport. Used to have pool, but not the last time I was there.

Karl Strauss Brewing Company Tasting Room

Definitely one of my favourite tasting rooms by Karl Strauss! Also, check out the restaurant chain run by the same folks.

Mission Brewery

Popular brewery tasting room.

Mother Earth Brewing Company

Brewery that tastes good.

Restaurants

Pomegranate

Best Russian restaurant I’ve found on the west coast so far. Back when I came here, they took only cash and didn’t have a liquor license - now it’s a full-fledged restaurant with everything you’d expect.

Karl Strauss Brewing Company Restaurants

Fantastic chain of restaurants (there are quite a few beside this one) run by Karl Strauss Brewing Company. Also, visit their tasting room!

Board and Brew

An awesome sandwich shop that by now expanded its chain as far as LA. This is the original one, though surprisingly is one of the few that doesn’t serve beer, so you may want to check out of the one in Encinitas.

Brigantine

The only thing I ever go here for are fish tacos. Ask for their hot sauce and sit outside overlooking the historic race track.

Regents Pizzeria

Some of the best pizza. They used to be absolutely tiny and hosted 2600 meetings.

Continent Deli

Great Russian foods store!

Isabel’s

Tasty brunch place!

Enoteca Adriano

Good Italian food I’ve been to a couple times.

Davanti Enoteca

I’ve been here for spritzes and appetizers once - was good!

Coffee & Tea Collective

Good coffee!

Shops

Stereo Unlimited

A huge music store: they have four or five rooms full of vinyls, several rooms of home theatres and know their craft well!

Poway Motorcycle

No one ever takes their bikes to shops, but if you ever ride down to San Diego at night in the rain and realize your tire shows wire at the same time as you blow through the rear caliper and leak all your brake fluid onto the tire - go here. They’re fantastic dudes and are cheap.

North Coast Photographic Services

Extremely professional photo services shop. If you still shoot film, this place is pricey but are the best in the area.

Ballast Point - Home Brew Mart

Ballast point is a brewery that runs this shop for homebrew equipment! Definitely bought plenty of stuff here back in the day.

Beaches

Cardiff Beach

Not a lot of people know about it, and even less can find parking here - makes it for a perfect spot to come to on a motorcycle. Park right on the highway and don’t pay fees!

Black’s Beach

Nude beach that’s pretty hard to get to.

Sights

International Friendship Park

A park on the border with Mexico. Far to drive to but absolutely worth it.

Don’t pick up hitchhikers probably.

Del Mar Airport viewpoint

Del Mar used to have both an airport and a train stop - the former no longer exists, the latter is still there but closed. Linked spot is a neat viewpoint on where the airport used to be.

Pirate Caves

Somewhere in Ocean Beach there used to be an extensive network of caves said to have been used by smugglers back in the day. It’s been filled with concrete at least twice, and last I checked - they’re still shut. Contact me if you want the exact location.

Slava I. Maslennikov

Learning

Engineer Experience

An engineer’s needs

Communication

Daily routine

Ease of engineering

Bureaucracies

Projects

Growth

Compensation

Feedback process

DevEx

Further reading

Conclusion

READABLE documentation

Individual need

Use your silly voice

How to come up with an acronym

Simple structure and flow

Automate instead of document

Yerevan

Overall

Yerevan

Lake Sevan

Dilijan

Garni

Garni Temple and basalt formations

Interviewing engineers

General approach

Rounds

Ending a round early

Take-home tests

The interview rounds

Technical round

Behavioural round

Leadership round

Wrapping it up

Personal horror stories

Reading obscure bash

Caveats of buying a house

Overall process

House searching

Agents

Manufactured homes

Submitting an offer

Loans

Pre-qualification

Loan terms

Closing funds sources

Homeowner’s insurance

Closing procedures

Appraisal

General inspection

Pest inspection

One year later

Moscow

Generics

Getting around

Payments

Cell phone and bank accounts

Restaurants

Stores

Excellent Code

Design and planning

Compiled, interpreted and scripting languages

Documentation

Code versioning

Local development environment

Automation

Conclusion

Further reading

Fairness and Law Enforcement

A counter opinion by Lev G., which I have not yet formed a response to

San Diego

Breweries & Bars

Restaurants

Shops

Beaches

Sights