Building technology, bringing business to life
Building technology, bringing business to life
IT Woes. Part 1: Blown Deadlines.

Alex Rogachevsky    May 10, 2018
This is the new series about my IT engagements, showing project problems I’ve encountered during my career, and their solutions. I’ve seen everything over 25+ years. Servers crashing every five minutes, the runaway defect rate, key developers leaving due to the hostile environment…
Not going to name the people or companies, as I am sure they learned their lessons. I am an engineer, so for me the 70–90% IT failure rate is about the opportunity to solve the problem, rather than place the blame and climb the corporate ladder.
Most of those problems, including seemingly organizational ones (communication issues, poor motivation, etc.) are 100% technical. I’ll explain later. I am an engineer, and that’s what we, engineers do for living: unconditionally solve problems instead of facilitating and mitigating. I’ll start with THE most common problem in my experience: blown deadlines.

Object-Oriented or Functional? Just Write Quality Code.

Alex Rogachevsky    May 4, 2018
That’s right. Who cares? Just write good minimalistic code. Does it make OOP and FP unimportant? No, it makes them equally important to write quality code.
Before I continue… This post is for programmers. I am not going to explain OOP or FP, referring to “fundamentals” from Knuth, Dijkstra, or Stroustrup. One of the reasons behind today’s disdain for OOP is purists’ pet peeves. Sorry, if you are expecting linguistic discussions comparing Haskel vs. Smalltalk or praising Clojure, you won’t find any in my post. There won’t be any “Hello, world!” level code samples either. I merely want to explain how you can turn your expert programming (OOP, FP, etc.) skills into money, the chances are your bosses are not paying you.
It is worth to point the relationship between OOP and FP though.

IT Meritocracy. Part 12: We Will Pay Google Wages.

Alex Rogachevsky    May 2, 2018
This is the last article in my Meritocracy series and I want to go on record. It’s not worth going through the pain of founding a software company self-funded without a goal of making it big — to afford practicing what you preach.
No, my goal is not sticking it to Microsoft, Oracle, and the rest of the Great IT Consulting Food Chain happily charging its man-hours. It is to restore meritocracy (meaning fair wages) for the select few: generalist- and founder-level enterprise software developers.
How Long?
It took Google about 15 years to offer its engineers the current compensation. We’ll always have orders of magnitude lower headcount (per programming task/project). With less mouths to feed we hope to reach the point of “Google wages” much sooner. Like any startup, we’ll pivot a lot, but with so many lessons already learned the future looks solid.
We are confident to launch self-funded and start offering developers $300–400K compensation packages within five years.

IT Meritocracy. Part 11: The Holy Grail of Enterprise Software Development.

Alex Rogachevsky    April 29, 2018
How would you build a Google-quality enterprise system, since Google doesn’t have a “developer’s guide” for unscientific enterprise software it avoids like a plague? By using Google and/or Facebook tech, right? Are you already? Using Google Maps API and storing data in a Facebook-originated Cassandra database? Great! How do access Cassandra? Through the same DAOs and DTOs, code monkeys write, since it’s a “J2EE pattern”? You saw it coming, didn’t you?
Using the latest software development tech, whether from Google or some unknown GitHub repo, is implied. I am asking about quality programming. Do you write object-oriented and functional code of Google’s quality: minimalistic, neat, robust, orthogonal, and easy to extend? When was the last time you used OOP to model business logic? Am I talking gibberish? C++ and its successor Java were invented to model complex real life entities and processes — not to write structs with functions.

IT Meritocracy. Part 10: What B2B Software Is Worth $400K Wages?

Alex Rogachevsky    April 25, 2018
TPS reports are most certainly not. IT bosses have insisted for decades, that programming is an Accounts Receivable kind of commodity, at least outside a handful of “scientific” Googles of the industry. Is it? Do we, enterprise software devs, build anything better, than TPS reports? Products that deserve Google Level 6 compensation.
A better question is, if what we are tasked with (and paid accordingly) at our day jobs is what the real customers need. The money ultimately comes from them, not your boss. So… if your job was perfect, what would you build there to challenge the “big tech” (Google, Amazon, and the likes) with your programming ingenuity?
Here we are: wondering if the effort to solve a non-trivial paying customer’s problem, will ever translate into wages comparable with the B2C industry, offering “free” blog platforms, messengers, and games to make money on ads.

IT Meritocracy. Part 9: Is Unscientific Enterprise Software Worthy of Google Compensation?

Alex Rogachevsky    April 21, 2018
Be Selfish When it Comes to Your Income.
I am ashamed to admit, that my entrepreneurial drive to develop the next generation of robust business software for information-centric SMBs at the fraction of Oracle and Salesforce costs is largely based on the denial of the new, slashed in half IT wages and relentless (engineering) attempts to restore my compensation to the pre-outsourcing level.
It’s hard to say, if I would have come up with Px100 out of boredom, if the “evil” corporate IT paid me $300–400K a year — currently Level 6 wages at Google. Amazon, Facebook, and Google don’t want me, along with the 99% of programmers on Earth, specializing in unglamorous and unscientific enterprise software. Mind you, their recruiters reach out to me every year. Doesn’t mean much, since I have no dissertations or “algorithms” to impress anyone interviewing me there.
Is it selfish to equate meritocracy with money? Wish everyone was driven by such “selfishness” and asked “What’s in it for me?” when it comes to income. No politician (or employer) would be able to play their games, forcing or tricking us into money-losing decisions in the name of something “non-material”: wars (on drugs, terrorism, whatever) or equally mythical “perks” and “work-life balance”. Start thinking about your own pocket, and everything will become crystal clear.

IT Meritocracy. Part 8: Don’t Beg Google for a Job.

Alex Rogachevsky    April 12, 2018
Take its open-source tech to build your own future.
Object-oriented purity, little exception handling frameworks, and neat database access wrappers bring great satisfaction during the learning phase. Algorithmic exercise proficiency and hackathon wins make one proud too.
No offense, but that’s (for the lack of a better term) childish or developmental meritocracy: potty training if you will. Sure, a few reputable employers (Amazon, Google, etc.) love potty-trained (algorithmically proficient) kids they can groom according to their agenda. I don’t want to stir the leaders vs. followers debate. I admire the current consumer tech leaders. But despite my very open mind, I’ve always had a problem with grooming.
In any case an ambitious (and thus underpaid) developer is only worth grown-up compensation upon, well, graduating from the potty-training and elementary reading daycare.
Let’s not idealize Google or Amazon. Let’s not rationalize their hiring criteria to prove it right or wrong. Yes, it hurts one’s ego to be rejected by any of the top tech employers: legit (compared to dysfunctional corporate IT) and contributed a lot for our civilization, but for the most part they are irrelevant for your professional and financial future.

IT Meritocracy. Part 7: Why Don’t Our Bosses Just Let Us Do Our Job?

Alex Rogachevsky    April 7, 2018
Someone asked me an interesting question on Quora.
As a software developer, is it normal to always feel that you are unable to do your best work, due to budgetary concerns upstream?
Not sure which IT atrocity frustrated him. Was he rushed by his non-technical boss, clueless about programming intricacies behind a seemingly simple UI screen? Only programmers are aware of tricky API calls, clever database query optimization, relentless hacker proofing, and other security measures. Was he treated like a mindless assembly line worker amidst attempts to solve complex problems via brute force? Our bosses hire cheap code monkeys instead of giving one enough time to eliminate the issue for good with the right technology.
Why don’t they leave us alone and let us do our job?
There is no black and white answer. I am my own (worst) boss now. The question simply transformed into: "Am I balancing my perfectionist urges and the business needs?"
No clueless non-technical bosses to blame anymore. It’s just me.

IT Meritocracy. Part 6: Everything Is About Technology.

Alex Rogachevsky    April 4, 2018
The Soviet Union I grew up in, was an oppressive Orwellian state. However it had none of the modern Western BS about “choking hazards” and various lawsuit-inspired safety labels. I played with finely-detailed hobbyist-quality East German toy trains and realistic-looking toy guns. As far, as I can remember, Lego blocks were normal (small) size too.
One can build infinite number of cool things (see the F1 car above) out of universal Lego blocks. It wasn’t until I became a parent (here, in the US), that I discovered different chocking-safe Lego for toddlers. Its big crude blocks immediately reminded me of countless attempts to replace programming with DIY software “building”. All of them: from COBOL to present day CMSes and DMSes have failed — to deliver robust industrial quality software.
Software is the same set of programming instructions to the computer, whether it is consumer blog platforms or enterprise systems. Both have UI, business logic, users/security, notifications, databases, and other universal Computer Science concepts. So why the enterprise software industry continues its attempts to dumb down programming even today, after seeing how well the consumer tech: Google, Amazon, Netflix, Uber did without “simplified” tools and languages?

IT Meritocracy. Part 5: Wooing the Rich and Influential.

Alex Rogachevsky    March 28, 2018
Alright, you have the superior equipment and you trained yourself to pedal in a higher gear. What’s next? I already talked about it in the previous post, comparing programming to sports. It’s enrolling in a pro competition to win the pro prize. So, is it your responsibility or someone else’s duty to notice your professional excellence and bring you in?
Yes, everyone knows, the demand for pro athletes in our filed (software) is higher than ever — regardless of the number of code monkeys in today’s IT. Slave labor doesn’t work — to build anything real. Only to log hours to make staffing middlemen their commissions. Worse, a lot of things needs to be rebuilt after such man-hour-driven amateur commotion, making pros even more important.
The demand itself doesn’t get one hired. Or the startup magically funded. You are still asking a lot — for someone to build the environment around your specific strengths, matching them against the specific customer demand — let’s be honest, you haven’t a slightest idea about. Someone needs to find those customers for you, right? Let’s talk about it.

IT Meritocracy. Part 4: Pedaling in a Higher Gear. Is Writing Less Code Better?

Alex Rogachevsky    March 21, 2018
The focus of this series is less programmers doing more — by writing less code. As you can expect the new kind of code is more “concentrated”. Is it actually the solution — to balance the world’s demand for quality (the only kind) of programming vs. the finite number of pros capable of delivering it? Is writing less code (to cover the same amount of product functionality) always better?
Don’t rush with your answer. I think I went to the extreme, and would like to tell you my story and conclusion. Unless you went and tried, like myself, you’d never understand the issue.
All linguistic (i.e. infamous Haskell and Go vs. Java) or puristic (OOP, FP, etc.) arguments are theoretical. Everything depends — on the task at hand. There are times to normalize and denormalize, to reuse and copy-paste. The only measure of the code quality is the end product’s quality itself i.e. how fast it was built vs. covered functionality, ease of use, and ease of change: future extensibility. And of course all of that is expected to just work — with minimum bugs and maximum uptime. Nothing else matters. Certainly not one’s desire to show off at algorithmic contests or put trendy abbreviations on the resume.

IT Meritocracy. Part 3: Hiring Binges — Fraud, Incompetence, or Technology Limitations?

Alex Rogachevsky    March 14, 2018
Hope you are enjoying my series. The previous post talked about fewer programmers doing — and earning more. I don’t preach. I practice — obviously in my own company. Never was allowed to do that during my corporate IT career. Staffing middleman interests aside, I’ve heard countless bloated headcount from both non-technical managers: “We are not Google” and, I kid you not, developers too: “But don’t you need a team?”, “Duh/Why?” (after showing one how to cut the amount of code to write 100x), and “I am not comfortable with such extreme focus” (after showing my colleagues one of my indented bullet point task lists I copy-pasted into the first article in this series).
What is really driving headcount explosions and why the Earth is running out of programmers even after annexing densely populated “offshore” heavens like India to the Western labor pool? As an engineer, I tend to think (inadequate and stagnated) technology is the culprit, however let’s examine other factors: fraud and incompetence too.
I heard the phrase “We are on a hiring binge” from one CFO during a typical life or death negotiation over a $10K to bring the salary to the upper industry average ($150K in 2013 if you are wondering). I’m sure you have plenty of similar experience. You know what recruiter confessions of “needing to fill 15 Java reqs” mean. Why they arrogantly (or stupidly) bring it up in emails to candidates is beyond me. Perhaps hinting at a well-funded project — from their perspective. They need to share the joy of those “requisitions” and “job orders” I guess. What it really means for you (the merchandise being sold) is the low compensation — opposite of the fewer people doing and making more approach I outlined in this series.

IT Meritocracy. Part 2: Less Programmers Making More.

Alex Rogachevsky    March 7, 2018
Let’s skip the debate of Austrian vs. Keynesian economics i.e. whether one’s professional excellence (production) automatically sells and thus should be recognized and rewarded regardless of the customer demand.
IMHO there is a huge demand for next-generation (business process automation) software, albeit only noticeable after one stops thinking of reinventing Facebook or Snapchat. Compare some slick consumer product e.g. a smartwatch app to the grayish Win95 era application you use at work. If not an alphanumeric mainframe terminal — still seen at most auto dealerships and half of retail stores. Who cares, right? That ancient crap works. If every engineer used the same “good enough” logic, we’d have still walked around with brick phones and pagers.
Assuming your product is craved by the customers, what would your, programmer’s compensation primarily depend on? Right, the development costs. If you are stronger and smarter, than others, your output will be greater and thus the same or better product, comparable with your competitor offerings, will require a smaller team of experts like you. Less people making more. Doesn’t get any simpler, does it?

IT Meritocracy. Part 1: Can You Found Your Current or Other Known to You Employer?

Alex Rogachevsky    March 1, 2018
I discovered programming in mid-80s at the age of 13. There were no personal computers, let alone smartphones. Our (middle and high) school rented 1/3 of two floors to some mysterious data center, which had AFAIR two CM-4 minicomputers: Soviet ripoffs of PDP-11. A couple of other, luckier schools in my two-million city (Minsk) had “proper” kids’ computers: ripoffs of Commodore and Apple II. Though I do not regret, that my first OS was UNIX and first languages: FORTRAN and C instead of the proper BASIC.
Fast-forward to my college years, I got my first internship at the AI Lab of the National Academy of Science during my freshman year: 1989. It happened by accident. My family had no industry connections whatsoever and I needed access to a computer. Any computer. Turns out state-funded scientists had them.
The following year I got a part- and then full-time job at one of the three software companies in the same two-million city. The economy completely collapsed following the fall of the Soviet empire. Not that it had too many (non-military) software development opportunities during the Soviet era. My family had relatives in the US, so those doors were permanently closed for me. Luckily the communist regime crashed just in time.

My Sourcing Experience: vs. LinkedIn.

Alex Rogachevsky    February 4, 2018
This post is for my fellow Belarusian geeks. Curious how your online profiles look to a boutique employer? I hope less technical readers would find it entertaining as well.
I've been mercilessly “recruited” for the last 25 years. I've interviewed recruiter-supplied candidates for the last 10 – with a various degree of success. And now I finally tried recruiting somebody. Why I did it?
We need a couple of skilled devs right now. My co-founder has a recruiting background, albeit in the medical and automotive fields. He called my recruiting efforts “cute”. Could I task him with it instead of taking the whole week out of my impossible schedule? Not really. We decided to recruit in Belarus, where I spent the first 25 years of my life. Therefore we needed someone Russian-speaking. I also foolishly believe that a technical sourcer beats a non-technical one.
I know it was wrong to spend even three days (out of seven) on sifting through 2K of candidates ( and LinkedIn combined) to select about 350. Reading everyone's (poorly written – I'll get to it in a bit) profile, looking for traces of contact info (by following GitHub and other links), and copy-pasting it into a spreadsheet, since LinkedIn has no export function. No one does it like this. No recruiter goes through that agonizing experience.

Dev’s Perspective: Money vs. Happiness - Eat Your Cake and Have it!

Alex Rogachevsky    September 12, 2017
This the first of my Dev’s Perspective articles, focusing on the current (end of 2017) career and entrepreneurial options for ambitious software engineers.
I want to be very clear from the start. Anyone ambitious and passionate about programming (practical engineering, not abstract computer science) should end up an entrepreneur. I wish I listened to this “cliche” 20 years ago, when I came to the US, or even five years prior to that, when I started my IT career in Belarus. What doesn’t break us (20 painful years in progressively “outsourced” American IT), makes us stronger. I wouldn’t be pursuing the next gen enterprise software, if I didn’t learn what to do and most importantly what not to over the last two decades.
I am going to talk about what I know: enterprise software i.e. data-centric systems with data entry UI, databases, reports, robust role-based security, complex workflows, and deciphered (intentionally convoluted) business rules e.g. of compliance nature.
It is hard, dirty, and very unsexy compared to consumer tech. A handful of top tech employers: Google, Facebook, Amazon, and others don’t want to touch always custom mission-critical business software with a 10ft pole. It also has zero hype-ability and “exit” potential for Silicon valley VCs compared to the current fad: AI and ML.
If you are looking to jump on one of those bandwagons (good luck w/o MIT credentials or money connections), or want to reinvent blogs or crypto-messengers for the 100th time, don’t waste your time on my series. Go back to reading Zuckerberg’s biography and envying Elon Musk and the rest of the “PayPal mafia”. If you however want to convert something you’ve mastered: your mad business software building skills into money, stay with me.

Dev’s Perspective: American Software Engineer Compensation.

Alex Rogachevsky    September 12, 2017
First off, the numbers. Corporate IT (IT departments of non-tech corporations, Initech-size software sweatshops, and the members of the Great IT Consulting Food Chain: from Oracle and Deloitte down to boutique “architecture” firms) currently pays senior programmers $140-180K - essentially the same number, it paid in the 1990s ($90/hr == $180K at 2080 work hours in a year).
Inflation-adjusted (see a very conservative calculator here: it should have been double: $300-400K, which is not surprisingly Google’s Senior Staff compensation in 2017. Yes, you can go to Google, for all I care. I’ll cover it in another article. Read the first one I mentioned above for my reasons to limit the discussion to mission-critical enterprise software, Google doesn’t want to touch with a 10ft pole.
I’d also like to clarify, that I am only talking about accomplished aka “senior” and “team lead” level engineers. Junior and mythical “mid-level” compensation is not worth discussing. If you love programming, you grow to the “senior” level i.e. the ability to work w/o supervision among other things, in the matter of months. If you don’t, choose another profession. Yes, this is Sparta. The industry should employ significantly less people and pay them significantly more. Engineers used to make more than doctors. Sounds like your kind of world?
So, why and how IT sliced the wages in half (it’s a bit more complex, than just “outsourcing”) while Google increased them to maintain the 1990s level? And how one can arrive at that upper middle class income - w/o working at Google?

Dev’s Perspective: IT Job Market Supply and Demand.

Alex Rogachevsky    September 12, 2017
The previous article explored the wages and pinpointed the problem - zero demand for capable programmers in corporate IT.
It may seem at first, that the current IT wages problem is caused by the supply. After a hungry billion-population country joined the Western job market, duh?
Not to mention that all markets: from stock exchanges to employment are heavily manipulated. Dark pools and price fixing are easier than ever in the age of internet, with the government looking the other way, as usual. You wouldn’t expect people you support with your taxes to actually help with anything, would you? Are you really hoping that the legislature mentioned above would actually pass as is? Leading to some semi-official $130K minimum wage in IT? Keep dreaming.
The job candidate supply has been manipulated in American IT forever. Tell me why rare nowadays specialties like circa-1995 (Win95) MFC, popular in the Windows-centric defense sector, don’t command $300K+ Google wages? Not only those jobs are not outsourceable “offshore”, they often require a security clearance. Is it because the “private” defense companies are hurting for money? Obviously the “decision makers” got together and decided (or silently agreed) how much those engineers are allowed to make. Where is the supply and demand? Or it is evil recruiters jacking up their markups? Come on. No one would offer an MFC dev $200/hr: $150 to make $300K annually + 30% recruiter markup.
Things like that existed long before the mass “offshore outsourcing” of the early 2000s. They did affect the wages, but it was OK for the most part in the late 90s. What’s changed - fundamentally and across the entire industry? The demand did.

Dev’s Perspective: Who Needs the “Architect”?

Alex Rogachevsky    September 12, 2017
If, after everything I’ve told you about IT so far, a techie like you still wants to be a good corporate boy/girl, pleasing your bosses and serving the System, your only remaining option to maintain a mid to upper middle class income is to “grow” into a semi-managerial “architect”. Make no mistake. This not an engineering job. Pre-sales or post-sales, the so-called “architecture” is a client-pleasing sales activity, period.
I want my business partner Jason to master the art of boardroom architecture presentations. As for you, I’d rather have you working with me developing the next gen enterprise software Jason sells the sh-t out of. That’s in a nutshell my current success formula.
It doesn’t matter if you or I want to change the world for the better. It doesn’t matter if others make billions selling crap: meaningless consulting man-hours or AI vaporware. It doesn’t matter if VCs “foolishly” invest in the latter (no one “invests” his/her own money). Without “connections”, mortals like you and I need to do a lot of kiss-a$$ “networking” to get into the rich fraudsters club. I equally respect all tech-related activities: marketing, sales, and engineering, but born w/o a silver spoon in our mouths, we have no choice, but to offer our customers something real: the products and services they need and will pay for.
No pre-sales architects are needed to sell good working software. Google and other top-tier tech companies have none. The so called “architects” are “bodies” like bodyshop-supplied code monkeys churning out DAOs and DTOs.

Dev’s Perspective: the Myth About American Salaries.

Alex Rogachevsky    September 12, 2017
I’ve been absent from the Belarusian software development community for quite some time, living and working in the US. My recent conversations with developers: both the seasoned ones I’ve known since college and the new generation of engineers revealed the same mindset I saw 21 year ago, when I left. Let me address those myths, which I am pretty sure are exactly the same in many other countries.
It’s been 30+ years since the narrow Soviet engineer salary range of 120-150 roubles per month - for life. Today’s Russian, Ukrainian, and Belarusian salaries range from $500 to $5000+, based on a variety of factors, the technical skills being only a part of. Trying to find some average one is entitled to is myopic. It was like that during the Soviet era of guaranteed employment and frozen prices. That era is gone, so don’t compare one meaningless average to another from a different country. Software engineers capable of juggling 10 different concepts at once (the human brain comfort level is three) should know better.
They should also know by now how the “free economy” functions expense-wide: the official taxes, mandatory insurance, compliance, and other racket: forced services, designed to enslave the powerless middle class, making it live from paycheck to paycheck.
I’ll make it simple for you. It’s perfectly normal to be curious about others’ salaries, and despite the popular belief (and draconian confidentiality agreements) Americans discuss and compare them quite often. However, when it comes to income, you should always count money in your own pocket, not somebody else’s, or worse, comparing national averages. Are you average? I don’t think so. Then research the salary you’d get in the US - at your current technical and communication skill level.

Dev’s Perspective: Any Reward for Learning New Technologies?

Alex Rogachevsky    September 12, 2017
I am going to cut to the chase. Unless you are a total moron, an Ivy League MBA guarantees you a corner office. There was a time, when the programmer education credentials didn’t matter as much (compared to managers and lawyers). Outsourcing or something else, that time is gone. Get into CalTech, MIT, or at least Berkeley. Programmer career is no longer unique - exempt from the atrocious regalia grading of the rest of the white collar world. The CFOs dream came true. Software engineers are now the same, as mechanical and electrical ones: placed slightly above Accounts Receivable clerks. A$$-kissing politics and education regalia started to matter again in programmer’s career.
Isn’t it ironic, since the Medieval concept of an education shrine has completely lost its relevance, at least in the inherently virtual Computer Science? No one needs slots of shared mainframe time anymore to run a deck of punch cards. Any other expensive lab equipment?
No in-person mentors are needed due to vast social networks. There is plenty of guides for beginners wondering where to start. Everything needed beyond that level: API specs, well-documented open-source frameworks etc. is easy to find and free. The technical progress keeps making programming tools simpler and easier.
I still think all developers should attend a college - to test their IQ and stamina. But as far, as the college rank… I have one word for you: Coursera, if one ever needs to take a formal class to [re-]learn some fundamental.
Cutting to the chase again, you should only study something when you need it. Technologies change every year. It is impossible to memorize everything. And why? Contrary to Google and Amazon interviewer opinion, a software engineers’ job is not a continuation of midterm and final exams to test how he/she learned the new hot abbreviations.

Dev’s Perspective: Revisiting Job Hopping.

Alex Rogachevsky    September 12, 2017
I’ve written on this topic before. Granted the true engineering-centric employers have finally emerged: yes, Google and a handful of the top consumer tech companies, one shouldn’t plan to stay even there for life. And no, infamously cheap and exploitative Microsoft wasn’t such engineering Mecca in the 1990s. Nor IBM, Oracle, SAP, and other heavy hitters of the IT Consulting Food Chain before Microsoft.
The rest of the IT, where one is likely to start an enterprise software developer career, has become one giant Initech. It’s not all bad. Sure, corporate IT paid twice as much (inflation-adjusted) before the 2002 outsourcing bonanza, but it never provided even a glimpse of the solid career path Google offers. Meaning one had to change jobs to simply get a raise.
Job-hopping is your only option at the first job. Which, let me remind you again (after earlier articles), should be the place and time for you to make a leap from a junior to senior developer within six months or less. If you cannot do it, job hopping wouldn’t help. Cut the losses short and find another occupation.
If you can acquire expert programming skills within six months, they surely won’t be appreciated by your employer, since you’d be committing a cardinal HR sin of asking for a more than 3% raise. You’ll need to leave. Job-seeking (and hopping) is a confidence-building skill of its own, that relies on communication, networking, and many other things to sell yourself. I advise to at least try it.

Dev’s Perspective: Architect and Middle Manager “Offshorability”.

Alex Rogachevsky    September 12, 2017
I remember working at the headquarters of a well-known F100 company. Its IT was completely “outsourced” “offshore”. They brought a CIO from GE - specifically experienced in moving jobs to India. He was unceremoniously fired five years later after wasting $190M (unofficial number), but that’s a topic for another article.
I was surrounded by “discount resources” proudly displaying miniature Indian flags on their cubicles. No one bothered to speak English. But when they did, even the lowest code monkey used condescending PM lingo like “resource” and “offshorability”, trying to distance himself from the five times bigger workforce in India. The concept sunk in. Let’s talk about “offshorability” of software architecture and middle management, a senior developer may view as an outsourcing-free haven.
I’ve worn one or another architect title and a couple of managerial ones for the most of my corporate career. As you can probably tell by my opinion on the matter, I’ve been outsourced a lot.
You can read my take on “software architecture” here. I have enormous respect for Fowler and others, but if you stay in IT promoting the best of the patterns and architecture principles e.g. microservices, they’d still share the fate of Scrum - butchered by clueless PMs and hated by everyone. Have you seen microservices or Docker turn an IT department into an enjoyable workplace with fair compensation? Keep dreaming.
Solution Architects are often hired to communicate business requirements to the (always outsourced) junior coders. You may even think, that your ethnic background (Hindi-speaking for an Indian team, Russian-speaking for Russians, etc.) would be of value. Certainly. Your outsourced paycheck however would be a different story.

Dev’s Perspective: Is Google Still an Engineering Company?

Alex Rogachevsky    September 12, 2017
Google has arguably done more for our technology-driven civilization, than IBM and Oracle combined, though those old school companies made the essential inventions Google would be impossible w/o.
Having shown the proper respect, the past and even present doesn’t matter. The future does. Not the Forbes projections of Google “quarterly earnings”, but your own future at Google.
Quora is typically the best resource for Google, Amazon, and Facebook inside stories. I am not going to repeat or even link ex-Googler concerns about the direction of the company. You can find them yourself and, yes, ask “what’s in it for me?”
I can only tell you about my own (would be) employment experience with Amazon and Google. First, there were typical sourcing misses. No, those companies are not on a lookout for smart kids to find appropriate jobs for them. Nor Google and Amazon internal (HR) recruiters are much better than typical telemarketer-level sourcers harassing you daily. Second, when the stars align: sourcers doing their job correctly, you get to the infamous algorithmic interviews. There isn’t much to say about those, other than I am too old for that sh-t.
Honestly I was too old for those coding exercises even during my third year in college (“institute” as it was called back then in Belarus) at the age of 20, when I got my first big project: to design and implement a bond trading system. Fascinated by the first graphical Windows release, I failed miserably by trying to mimic the consumer (file manager’s drag and drop) UI. I learned my lesson. That failure and all successes and failures of 20+ subsequent multi-million projects had nothing to do with algorithmic aka “competitive programming” proficiency tested by Amazon and Google at their interviews.

Dev’s Perspective: Are All Self-Funded Opportunities Gone?

Alex Rogachevsky    September 12, 2017
If you read the previous ones, you know what to anticipate in the grand finale. There is no place for you in the outsourced corporate IT. There is no place for a passionate engineer at the academics-biased Google and Amazon. There is no place for you at “funded” Silicon Valley AI vaporware startups, unless they can hype your ex-Googler or MIT regalia.
I hate to sound like the old Soviet propaganda showed down my throat in the elementary and middle school. The industry was OK 20 years ago, but now it exists to exploit you - at best. And is slowly dying - the scary part. Not only the current System won’t reward your intellectual contribution. In most insuranceCases it won’t even know what to do with your inventions. You need to take matter in your own hands and build your own world outside of the current System.
The (seemingly) bad news is all easy niches being taken. No Yellow Pages like directory that made Elon Musk rich. It wasn’t black and white even in the tech-hungry mid-90s. Google and Salesforce were founded on true inventions, while Zip2’s sale to Compaq is yet another “exit”. Why not IBM or HP: in need of an online business directory engine too? One of heavy hitters on Zip2’s board made it happen, not Musk’s genius and charisma.
You can read the Zip2 story here. Most people prefer to talk about the more glamorous “PayPal mafia”, ignoring what made Musk rich, opening the doors to the big boys club, where financial startups are founded. We are starting exactly like him: self-funded. But the time of taking smart, ambitious, and hardworking kids, like Musk under the VC wing is gone. Unless one has an MIT diploma or Google on his/her resume; or an “industry influencer” daddy.
Startups have always played that game. I don’t think even half of “unicorns” came out of legit inventions even back then, when it was easier. Now it is simply impossible. The club of “serial entrepreneurs” and their buddy investors closed its doors long time ago. You can only start self-funded today.

Dev’s Perspective: 2017 Career Options for an Ambitious Software Engineer.

Alex Rogachevsky    September 12, 2017
I hope you enjoyed my series. Time for a recap. What are the current (end of 2017) career options for a founder-level developer? Founding his/her own startup? Of course, but it’s not so simple and black and white. Let’s list your options from best to worst.
Option #1: Your own company should always be your ultimate career goal. Don’t be like me hoping the job market would improve or someone takes you under his/her wing. However just wanting to be your own boss or even mindlessly pivoting is not going to bring you any closer to the financial independence. You need to be ready to strike.
Option #2: How to prepare to found your software startup? That involves suffering in the decaying corporate IT for a few years. Change several projects/employers carefully choosing their markets/niches - most suitable for your future startup. Observe, network, plan. Once you feel you stumbled upon something valuable, develop the MVP part-time, find a sales-savvy partner (we can help) and leave.
If you are coming to the US on an H1B, you’ll really have no choice until you get the Green Card. Use that time wisely: exploring niches and building connections (among the clients). Not pleasing your greedy bosses, hoping for a “career” at your bodyshop.
Option #3: Your next option is joining a legit startup founded by someone like you (or us). Grow with it to become a multi-millionaire. Or graduate from it and grow on your own - see Option #1. Not sure about others, but if it is us, we will support you in your entrepreneurial endeavours.

My Entrepreneurial Journey: 2017 Recap.

Alex Rogachevsky    August 20, 2017
I may be embarrassed of this article five years from now even more, than I am embarrassed of my 2012 entrepreneurial statements. Nevertheless I’d like to tell the inquiring minds where my LionStack partner Jason and I are today.
Here’s what I did before I met Jason:
  • Naively tried to turn huge custom ERPs into monthly-subscription SaaS.
  • Offered my partnership to a couple of people with trustworthy ideas, that needed an enterprise system, but wanted to manage a cheap freelancer.
  • Gambled on a flashy, but too disruptive (to please the industry influencers) consumer idea.
  • Saved and single-handedly rebuilt a data-heavy multi-million B2B SaaS as a private contractor - to leave that project in February to concentrate on LionStack.
Here’s what Jason and I accomplished in the last six months:
  • An equity-based three-platform professional network system for psychiatrists.
  • Several well-researched and prototyped pivots we can still return to: HRMS, high-end smart home server, and targeted CRM on steroids.
  • Dead-simple, but robust inside internal ticket system centered around developer needs.
  • Custom insurance CRM solution for a paying client.
  • Our first developer - to groom into a future technical founder.

"Work Hard, Play Hard" and "Work/Life Balance"... Run Away!

Alex Rogachevsky    November 10, 2015
No one will ever hear those silly statements from me at the interview. Some things are better left unspoken. People cannot openly call themselves pretty or sexy - unless it is a joke between close friends. With the exception of one cheesy movie Google doesn't advertise its work environment. Everyone knows about it. Google has worked hard to build that reputation.
So when some HR rep mentions the "work/life balance", he/she is waving a big red flag in the candidate's face. Why not simply say, "We pay well"? That's it. Pay me well, and believe me, I'll take care of my work/life balance better than anyone else in the world. I'll "play" as hard, as I can... afford.
What if my idea of "playing hard" is doing a trackday in a Lamborghini? Hell yeah, I'd work 12-hour days and weekends for that. Not so much for weekly team-building events at Dave and Busters. Am I too greedy?
Software engineers are six-figure professionals, not minimum wage workers happy about every perk. All "benefits" combined represent a rather small percentage of the senior software developer compensation package. Tacking something on looks like a cheap trick. Engineers are good at math, programming complex calculations every day.
Why to "sell" candidates the company at all? One can make tons of observations right when he/she walks into the office for an interview. Not by hip and trendy decorations, furniture, or computers. It is how people walk, talk, and smile. Do they look rested or they fought yet another 3am fire? It'd always show if they are confident and happy.

Anything Left of IT "Human Capital"?

Alex Rogachevsky    October 3, 2015
IT hasn't always favored "buy" over "build". It employed normal engineers doing normal software development 20 years ago. That era is gone.
The first exodus of IT talent was in the late 90's during the dot-com boom. It disrupted the normal career pattern of many talented engineers, who skipped necessary steps without proper intellectual contribution to earn their move to corner offices - the inventions they could have made in their engineering, not management role.
Worse, they were expected to become the next - younger and better skilled generation of IT leaders if they “grew” in IT instead of dot-coms. What happened to young people in corporate IT anyway? The new generation of engineers - to replace those who went to dot-coms in the 90's never came: scared off by the wage drop caused by offshore outsourcing. The damage is irreversible - serious generational gap in IT.
“Offshore outsourcing” was never intended to replace "onshore" engineering creativity. Cheap labor never does. But if generals gather huge armies of riflemen, they lose incentives to improve tanks, aircraft, and other advanced robotized weaponry. All of our Civilization's technical breakthroughs were aimed to reduce low-level labor - driven by the shortage, not abundance of workforce. Not surprisingly nothing has been invented in the enterprise software industry since the last leap - 1999 Salesforce SaaS revolution.
The scarce senior engineering staff that “survived” IT outsourcing was presented with a tough choice: to accept the falling wages or move to greener pastures - joining the multi-level IT Consulting Food Chain which traditionally specializes in selling expensive third-party software and support services. No more financial reward for solving IT automation problems, only sales of something already developed, and quite frankly needed to be replaced long time ago.

Two Challenges of Today's Business Software Development.

Alex Rogachevsky    September 10, 2015
Fighting business automation complexity is hard - way outside of the most brilliant and energetic consumer tech entrepreneur comfort zone. Otherwise we would have seen the new generation of enterprise software by now. No one wants to touch it. No one enjoys untangling redundant and convoluted government regulations - the main source of business automation complexity.
Two fundamental technical challenges continue to plague the industry. First, enterprise software is no longer a product one can build and sell multiple copies of. It would have been such in the perfect world free of convoluted government regulations. Today’s mission-critical business software is a service that primarily guarantees continuous compliance with those never ending regulations. The “initial” development never stops due to constantly changing business process and document flow.
This is the fundamental shift everyone needs to accept: designing software for change - as constantly evolving services instead of “customizable” products. And no, hosting such product online to join the “SaaS” club does not automatically turn it into a service.
The second and much bigger problem is satisfying unique customer needs. Not two businesses are alike. Generic accounting and CRM apps may only need a few "tweaks" for the particular user, but robust specialized software is custom by nature. Not “customizable” - custom. Even if the difference between two customers’ business processes is only a couple of fields or reports, at the current software development level, the amount of code (and personnel) required to support those two versions is comparable to developing two brand new systems instead.
“Customizable” is perhaps the biggest industry myth. Heavily “customized” products mean only one thing – they are generic to the point of being useless out of the box.

From 4GLs to Targeted Frameworks.

Alex Rogachevsky    August 2, 2015
Ever since the granddaddy of "business-oriented" software development tools, 1960s COBOL, their creators felt compelled to target semi-technical (at best) power users instead of normal programmers.
Classic programming languages like C/C++ and Java are "orthogonal": allowing the programmer to express absolutely anything with a minimalistic command set. Business-oriented, data-centric and other so-called 4th Generation Languages (4GL) are the opposite - envying English with hundreds of special keywords, suffixes, prepositions, and complex grammar.
Not surprisingly those languages are extremely hard to learn. Sane "semi-technical" users stay away from such "convenient" tools, leaving them to the special class of programmers - driven by money. I refuse to believe anyone who loves programming is enthusiastic about ABAP or Apex.
What really puzzles me is... with all variable declarations, if statements, loops, and other programming features completely foreign to power users, why not just make a business-specific library for C++ or Java and offer it to programmers? Visual tools can generate C++ or Java code. Make those WYSIWYG designers IDE plugins, and the IDE will take care of the rest: compilation, deployment, versioning, etc. That is current Oracle "middleware" - Java libraries and tools developed by companies it acquired.
The problem is, the aforementioned libraries are heavy multi-purpose old-school frameworks. Even horrible 1990s 4GLs and mid-2000s BPMs could have had a chance if they weren't so generic and bloated with "just in case" features. Some technologies are better off conceived by engineers, than marketing departments. No other agenda, than helping your own staff - and no one else - to become more efficient by targeting their specific challenges within your specific domain.

"Bricks" and Pagers.

Alex Rogachevsky    July 15, 2015
We laugh at 1980's “brick” phones, but only a fraction of the population could afford them at the time. And now everyone carries a slick touch-screen computer in his/her pocket - more powerful than multiple rooms of mainframe equipment.
Despite all the amazing advances in consumer technology, business software has been stagnating for 15 if not 20 years. Corporate IT is still in the “brick” era. Rewriting some of its software in “modern” languages changed nothing, as it is still based on 1970s mainframe architectures.
A “brick” is a “brick” - even fitted with backlit buttons and color display. What makes it a “brick”? Not the size - price. Something that still costs a fortune (in customization and support fees for enterprise software) decades after its invention is... well, a “brick”. Something that barely performs... Mainframe-conceived architectures can no longer handle increased business process complexity.
Technology stagnation affects everyone - primarily smaller companies that cannot afford “bricks”. As unreliable and feature-poor, as “brick” phones were, the only affordable mobile communication solution of that era was little pagers. That's what SMBs use today - little beepers of enterprise software: spreadsheets, simple accounting programs, and cheap CRMs.

Get Out of the Comfort Zone to Win.

Alex Rogachevsky    June 20, 2015
I feel bad for being harsh on IT and overly negative about the current unfortunate state of the enterprise software industry. As much, as I'd like to impress the reader with breathtaking inventions or examples of 3am heroics fending off a vicious DDOS attack or otherwise riding in on the white horse to save the day (night in that case), successful software development is rather uneventful and boring. It just works... like your kidneys or liver. No one brags about his/her healthy internal organs. Now, when their efficiency decreases, it becomes a different story.
Software engineering has a lot in common with auto racing. Both are about two things: using 100% of your equipment capabilities and not making mistakes - rather than doing something dramatic to impress the spectators - IT bosses. Racing drama only happens at the back of the grid between rookies. Watching top racers leading the pack through the race is boring. They don't show off. They simply follow the racing line and concentrate on being smooth. They know when to shift, when to brake, and when to get back on the gas. Firmly, but smoothly, precise to the millisecond - lap after lap after lap...
Expert Java developers leverage powerful tools e.g. Spring Framework to the fullest - like Michael Schumacher (with hopes of full recovery after his skiing accident) operates F1 cars at their 100% capacity whether none of us, "spirited commuters" would even complete a practice lap without stalling it.
Unlike Michael Phelps, Kobe Bryant, and other athletes that possess certain genetic advantage over the rest of the population, anyone can technically become a top F1 racer like Schumacher. Operating a car does not require any special strength or agility. Schumacher wasn't born an F1 champion. He became such because others - given a chance - chose not to widen their comfort zone to calmly operate a car at higher speeds - processing the rapid stream of sensory signals: image, sound, and tactile feedback, even smell - yes, without making mistakes.

3rd Generation Data Persistence.

Alex Rogachevsky    June 12, 2015
Data persistence is the most fundamental concept in business software. The current technology is based on the second, "relational" generation of databases. Storing data "relationally" in indexed tables was a huge leap forward compared to mainframe era flat files. The infamous Y2K crisis exposed the flaws of flat files, as changing just one field from two digits to four (storing the year as four digits) became a painful and expensive process.
Relational or not all databases share one serious flaw. They are disk-based. Even after the last mechanical HDD is replaced by fast flash storage, the "freight" block-based nature of disk I/O remains fundamentally different from frequent fine-grained RAM access - hence the need to pack and unpack small data units into those "blocks" to minimize the number of expensive round-trips to the storage.
30+ years of perfecting data transportation logistics brought us indexing, partitioning, query optimization, batching, caching, and many more amazing improvements. ORMs hide all of that from programmers making the database look “object-oriented”. That illusion however can only go so far.
Despite the most brilliant attempts to automate four fundamental data transfer operations: Create, Retrieve, Update, and Delete (CRUD), tedious CRUD plumbing still comprises 90% of conventional business software code. A much bigger problem is CRUD’s inherently procedural nature, which fundamentally conflicts with Object-Oriented Programming (OOP) used to model complex real-life objects and processes.

Initech Didn't Burn Down. It Survived Two Recessions.

Alex Rogachevsky    May 5, 2015
Anyone who worked in IT longer than a year would have enough material for ten "Office Space" movies.
We've already had two "recessions" in this century. Recession hiring patterns are fascinating. So you, Bill Lumbergh, hired some expert "unbelievably cheap". What's next? Other than "getting your money worth" through unpaid overtime, nagging "we pay you more than anyone" and other managerial necessities. Why it always comes as surprise, when that person leaves at the first sign of economic recovery? You didn't see it coming? You expected him to politely knock on your door and ask for a raise - after countless "How much we pay you" remarks? What are his chances of getting a raise?
Of course, you feel generous today. Throw him $1K and take him to lunch. He should be happy. And if he refuses your generous offer, you'll start shopping for his replacement at the same exact rate plus $1K. Why'd anyone do it - knowing the recession is over?
If you are "lucky" and the person stays, that's even worse. It may not be immediately obvious, but you shot yourself in the foot by paying your top engineer below the market rate. From that point on you cannot hire anyone at the market rate. You'd have to raise at least one person's salary, and the chances are many more underpaid employees in your company/department would ask for a raise too. Pray, that your engineers won't miss a day at work, because they are all you are going to have.
Third case, if you are hoping to get rid of your worst employees through "attrition" by not adjusting their recession-low salaries for inflation, those will never leave. The strongest ones do. How good is your math? The cheapest completely useless Java programmer still costs above $100K with mandatory benefits and taxes. If you hired such weakling for "simple support" or "just in case" when you had the money, plan on keeping him/her forever. Those are the ones behind the worst examples of "job security" via obscure overcomplicated design and code. You didn't see it coming either, did you? Non-technical managers wouldn't catch it in time anyway. How I know you are non-technical? You are bad at math.

Malignant Glue Code: Layers, Tiers, and "Enterprise Integration".

Alex Rogachevsky    May 3, 2015
Introduced in 1997 by Microsoft, three-tier DNA architecture was mind-blowing - a big step up from the two-tier "client-server" design pioneered by Oracle Forms in the early 1980s. Everything seemed perfectly logical: the client-side Web browser, the traditional non-Web enabled database, and the new tier - Web Server, which connected both.
Everything checks out in theory. Layering and modularization represent two fundamental OOP principles: encapsulation and separation of concerns. However in real life Object-Oriented, data normalization, and any other purism is nothing, but someone's pet peeve.
People are free to organize tools in the garage or mugs in the kitchen cabinet - by size, color, or any other way he/she feels is important. But plumbers don't "organize" water pipes "hierarchically" with different circuits for kitchen sinks, bathroom sinks, and toilets. They only distinguish between hot and cold water - striving for less piping and joints. Software plumbing needs to be simple and efficient too.
A few years ago I had a chance to compare my approach against the ubiquitous multi-tier architecture. Coincidentally one of my own project tasks was almost identical to one of my "day job" assignments: to implement a screen with seven fields: loaded, updated, and saved into the database. The screens had different purpose: global system settings and password policy enforcement, which is not important implementation-wise. It took me 10 minutes to implement and test my screen - writing just two files: the data entity with seven fields and the UI mapping for them: 15 lines of code total as I recall. The screen for my day job project took 6 hours: to write 5 new files and modify 21 more to the total of 26 files and several hundred lines of code - just for a single data entry screen with seven fields.