acesubido

Buying Bitcoin isn’t so much a hedge against inflation as it is a bet that demand will continue to rise.

While I do agree with majority of your points, I think people are missing a crucial point why Bitcoin was made in the first place: the 2008 bank bailout. Buying Bitcoin isn't a bet that demand will rise, to BTC maximalists, it's a bet that a Central Bank will screw up. That spills over to mainstream hype, scams, and all the sleazy things people associate with Bitcoin.

It's not appreciated by majority of people right now. The USA, with the might of the dollar and the Feds, will keep seeing Bitcoin as a nuance, it's not surprising. The only places where a globally liquid asset like BTC is appreciated right now are countries with a weak central bank. Either the central bank is being cut off by trade sanctions and local businesses cant acquire USD so they go through BTC [0] or just the plain inability of a government to pay debt, and the currency devalues due to the mistakes of a few and ordinary people suffer [1] [2].

But right now with all the QE, that 2008 spirit lives on with that price ticker as Central Banks are bound to screw up somewhere in this economic uncharted territory.

[0] https://asiatimes.com/2020/10/iran-to-use-bitcoin-to-fund-im...

[1] https://www.bbc.com/news/business-47553048

[2] https://www.reuters.com/article/us-crypto-currencies-africa-...

And there are a ton of articles that talk about how microservices save you money over a monolith, but none include hard numbers.

Yeah, you can do that by collecting a ton of data related to development though. Breaking down sprints, correcting estimates, deriving cost from time per feature and salaries, comparing it over time across architectures; having to collect all these data from team members during development is way too tedious. It may hamper actual productivity just to produce a more accurate report that says "hey we saved money".

I'd bet there's a large co-relation between successful micro-service migrations and teams that don't squeeze metrics from every single action that each team member makes just to make more accurate reports.

Also, I have no data to back this up, as far as personal experience goes the reason why "hard numbers" are rare for "microservice vs. monolith savings" are because of 2 reasons:

1.) majority of software companies usually don't aim to put effort on collecting metrics for optimizing "savings"; they aim to collect metrics on growth/acquisition, churn rate, market share, customer service, etc. If a large organization wants to optimize savings they'd rather think of taxes, restructuring debt, moving server locations (cloud/baremetal) and other larger items. 2.) majority of software companies are not at that scale where it warrants a report with hard numbers.

Someone already mentioned it here, but Netflix has a lot of material on it, without the hard numbers of course. https://www.nginx.com/blog/adopting-microservices-at-netflix...

Usually development teams subconsciously quantify microservice migrations due to severe violations of DRY. Resolving DRY, opens you up to more business opportunities (both internal and external). A microservice allows you to move from just being an app, to being a platform. Customers and other teams in your company build on top of you. The move is not necessarily decided upon because it increases savings (this is also mentioned in that article from Netflix).

If 3-4 apps have a similar feature that needs building and maintaining, that feature warrants to be pulled out in it's own microservice.

I simply can't answer what BTCs and other crypto coins are actually good for.

Everybody here is missing out why Bitcoin was made in the first place: the 2008 crash.

The benefits of a globally liquid asset (not USD) will only be appreciated if you're living from a country that has a weak Central Bank.

- Nigerians use it to import goods from China. This guy can't source USD to purchase imports for his mobile phone business, so he uses BTC [0]

- Venezuela remote workers getting paid in BTC, because their central bank clamped down on USD inflow. They also didn't want to be paid in the worthless local currency. [1]

- Remittance shops in Hongkong are using BTC to settle remittances by batch. Buy and sell to the last mile instantly, no exposure to volatility. This gives them way better FX fees and faster settlement (30mins vs. 1-3 business days). They pass the savings down to their customers as marketing spend, or they pocket the change to increase profit [2]

- Argentina Central Bank is hoarding USD due to dwindling reserves. So they imposed a $200USD/month cap on individuals transacting with USD. People are flocking to BTC for remote settlement. [3]

- Iran hit with sanctions cant use USD. So they're working on laws to use BTC for settling imports with China. They even issued BTC mining licenses for private companies. [4]

I come from a country, where if you remit more than $10K outbound you'd have to: pay big fees ($200+), suffer bad FX rates, wait for 2-3 days, do a physical appearance at the branch for and pay documents/notarial stamps, sign forms, present and print out government ID's, just to say: "This is my money, I just want to send money to my dad overseas for medical purposes".

December 2020, my mom had received USD in her dollar account. She wanted to withdraw and convert it to help build float for the family business, the local bank didn't have enough USD. They told her it was a 6-week wait, lots of people lined up. Lol.

People from first-world countries have it good.

[0] https://www.reuters.com/article/us-crypto-currencies-africa-...

[1] https://www.bbc.com/news/business-47553048

[2] https://www.reuters.com/article/us-crypto-currencies-remitta...

[3] https://www.coindesk.com/crypto-is-booming-in-economically-c...

[4] https://asiatimes.com/2020/10/iran-to-use-bitcoin-to-fund-im...

10-20 year horizon: Battery Technology. Manufacturing improvements, improving density and cooling requirements, recycling economy, etc. There's a huge race first-mover race that Japan has made a government-backed consortium tackling on batteries.

Most visible effect would be smartphones and laptop charging times and charging cycles.

For cars and work trucks: aside from cheaper cost, it'll also solve range anxiety and charging times.

For solar powered homes, you can opt to store cheaply in your home for night-use instead of sending excess back to the grid.

Lighter batteries on drones would have a multitude of uses from industrial to space exploration.

Longer time horizon: electric-powered flight and electric-powered freight. It will drop supply chain expenses on a macro perspective.

Apart from saying you're a "generalist", how do you best sell yourself when you don't have a specialisation or a specific area you are focused on?

"I have a talent and process for evaluating new technologies at a systematic pace. This will allow me to produce the necessary POC that would help you to decide if a piece of new tech is the right fit for your business problem."

Usually that's the job description of an Enterprise Architect or a Solutions Architect. They usually start coding stuff for a POC, or put in initial devops tools/processes, dabble with new tech but not deep enough to be a specialist.

Bitcoin has been in an upward trend since early September for no discernible reason (to me at least).

I think it's mainly due to purchases from institutions that believe that Bitcoin is a safe haven asset during the lockdowns. The spiel is: it's protection from currency debasement due to Central Banks everywhere printing out at low interest rates for the pandemic.

- Square spread 50MUSD worth buys @ 10K USD early October [1]

- Microstrategy spread 425M buys from 9-10K USD around August - September [2]

[1] https://www.cnbc.com/2020/10/08/square-buys-50-million-in-bi...

[2] https://www.forbes.com/sites/christopherbrookins/2020/08/14/...

I got around 300+ kills, I did that just by standing at the corner of the map and waited for them. Since they move slow, the turn rate was good enough not to be killed no matter how many spawned.

2 things for improvement:

- Demand more mechanical skill from players: Scale spawn and movement speed higher every 30 seconds, as timer nears 0. Make bullets finite. You could also implement day/night cycle + fog of war.

- Addressing repetitiveness: Shorten to 2-3 minutes. Unless I missed something, give the game an objective other than accuracy and score (find and collect X pieces to win or capture the flag, etc)

Other than that, great job!

I've always found the Sentry Gun UI in Aliens (1984) to be one of the more realistically usable ones.

For personalities try Jason Friedman. Martin Fowler's Refactoring is a nice read too.

But personally, I'd like to ask what business goal are we looking to solve? Because regardless of how murky a codebase can be, if that codebase keeps hitting a business goal, then we really can't drive a change in practices.

So, we first present business goals. Here's a few examples:

If the business goal is to give better estimates for fulfilling custom features faster, then testing would be the first in the list. Not even the release process. Tests lessens cognitive load for developers when they're asked "how long can we make this feature?". They'll have an idea that it'll probably break a bunch of services, etc. a.) If you're in leadership, ask for tests when people make a PR. b.) If you're not in leadership, look for the smallest part of the monolith. Write 1 integration test, add a CI integration, put it in a PR. Co-workers would probably like that.

If the business goal is to give better SLA's (turn around time for addressing breaking bugs, scaling better), then the release process would come first.

Regarding technical debt: One way to address technical debt is to slowly address it by folding in the effort of cleaning and refactoring inside a feature request. ex: making a new form about 2FA takes 3 days, but you can say 7 and explain that we'll setup a CI test build, then hit and address some debt regarding User Authentication along the way.

It'll introduce as a "Clean As You Go" culture in the legacy engineering team, which will pay off in the long-run instead of having a huge amount of time just dedicated to addressing technical debt.

The danger of separating "address technical debt" as a separate effort is it sometimes results into some unnecessary abstractions and over-refactoring: i.e. trying to make certain things too generic, bordering on building a framework.

But then again, if the business goal was to make a framework for a business goal (maybe something the bizdev can sell), then it can definitely be made as a separate effort. Otherwise, it'll be seen in the bizdev as someone just "playing" around with tech.

I think scientists have made an overwhelming convincing case climate change is real and it's from an increase in co2, but I have seen no models that I can play with specifically predicting how it will affect certain regions..... I guess my point is the first step is better forecasting and modeling tools.

Crop yields per region: https://iopscience.iop.org/article/10.1088/1748-9326/aab63b

Also, this might help direct you in the right contacts for that first step: https://interactive.carbonbrief.org/impacts-climate-change-o...

Otherwise we really don't know what we are fighting, other than higher temperatures.

Pretty important to fight higher temperatures too though, wet-bulb heatwaves can kill even under shade. "Some people" won't "suffer"; they'll actually die. https://www.pnas.org/content/114/33/8746

they think of all the possibilities that go wrong and start from the edge cases inwards, which individually represent a small piece of functionality.

I would rather they deliver a working chunk and just log.error when missing information is present.

Another way to look at this: they might be "afraid" of doing log.error and thus trying to overpolish; it could be a symptom of a lack in internal alignment on how to support a customer or meet customer expectations when the code hits that log.error line.

Sounds like a scoping problem.

Balsamiq if I just want to get an idea across (layout, story boarding)

Figma for higher-fidelity discussions (colors, spacing, icons, etc.)

+1 to Logitech K380. The only con I can think of are the arrow keys, but overall the key travel and typing is really good.

So why are software companies so willing to offer more pay for a managerial role that is easy to hire for, and so unwilling to offer more pay for a technical role that is one of the hardest to hire for?

It really depends on which part of the "software world" the company is situated in and the value they put in engineering.

A lot of companies have this exaggerated structure to value the work done by the project manager and business analyst (usually spec-ing out work and abstracting customer interaction from the rest of the team). The effects of abstracting customer interaction allows them to be valued highly, which will make them reside on the top of the chain and get compensated accordingly. The rest of the team doesn’t matter that much as long as they’ve got the right qualifications to convert requirements into working code.

This stackoverflow answer will give you an idea:

https://softwareengineering.stackexchange.com/questions/4577...

In 2029? I don't mean to sound "apocalyptic", but currently we're on track with a lot of global warming projections, 2030-2052 is the 1.5deg temp projection (https://www.c2es.org/content/ipcc-1-5-degree-c-special-repor...). So by 2029 time we might be at 1.3 or 1.4.

I don't know much about other industries, but I do know what happens when there's a long and hot summer in where I live. The water shortage was so alarming in Manila this summer, so I expect water shortages in certain parts of the world to be more exaggerated than what happened this year. Any industry that deals to contain/service water/ice during heat waves will be raking in cash.

In 10 years? I guess, not. Maybe 20 or 30? The world will have a different set of problems 10 years from now. A different set of verticals, regulations to work with. A different amount of platforms or hardware (quantum computers, more accessible VR/AR).

Take for example the current situation with agri-tech (vertical), it's pretty boring because it doesn't pay as much as putting different colored boxes in web pages for advertisers. With that vertical, you also have to take in localization for a region. Agri-tech vertical is nowhere near "tech-saturated" in other parts of the world. Random thought: it wouldn't be far-fetched to say agri-tech would pay a ton more if global warming went crazier in 10-20 years.

In 10 years, we can get better tooling, but if regional regulations/laws hamper new tech, we'll see tech-startups develop for that specific region. Things like data privacy laws in other countries would lessen usage of public clouds and more in-house data centers. Trade-wars also spawn events like Github/Google blocking developers based in other countries, etc. So you'll see more startups taking advantage of that by developing localized tooling leveraging regulations and laws.

Take for example, Alibaba. 10 years ago (~2009), you wouldn't know about that company unless you're from China. Now they're the Amazon/Google for a closed-economy of more than a billion people, more than twice the population of US. Grab, Paytm, Line are just getting started. So we'll probably saturate in 20-30 years? We might see more or less of these companies though, depending on the different set of problems/laws we'll see in 10 years.

whereas Libra is a Plutocracy (you need to be wealthy to be one of the few)

Agreed. The same way governments require a large amount of capital to be a bank to ensure depositors of liquidity. You need to have capital to back the Libra tokens, otherwise it can get pretty scary, just like USD Tether shenanigans.

or even possibly a Kleptocracy depending on how they actually run it and what their true motives are.

Banks, Central Banks, Governments, etc. whatever. Their motives are exactly "secret" when it comes to managing currencies. They all gear towards enriching their currency and making it more valuable. So yeah for this "oligarchy", I'd bet it's the same, Kleptocracy it is.

That sounds amazingly dystopian. I mean, that’s literally a money built on an oligarchy. By design.

IMO, it's a small step towards a better direction. The "validator" consensus (oligarchy) is a much more transparent/inclusive solution compared to the closed financial ecosystems of Wechat/Alipay/Paytm/Grab. If Libra is an oligarchy, closed financial systems are dictatorships

This:

"There's a feature you and several other co-workers are building. The deadline is 3 days from now.

You and 'Co-worker A' are tasked in building a module of that feature. You've already written several classes and tried abstracting some repetitive parts that would allow you to hit the target deadline for the team.

However 'Co-worker A' has also worked on those same classes and wrote more methods that are too tightly coupled and doesn't read well underneath. He claims this is a better design than yours just to finish the feature and doesn't budge on changing it during code reviews.

How do handle this situation?"

I like this question since there's a wide range of answers of how people deal with conflict under pressure.

the grunts who get assigned more menial pieces of work

Funnily enough if you automate and re-architect those menial pieces of work, you will turn that pile of boredom into a "serious growth prospect".

Does anyone have similar or contrasting experiences?

The grass is sometimes, not always, greener where you water it. I've been in that position, most of the boring stuff for me are related to internal operations. "High profile pieces of work" usually equate to "greenfield" customer facing UI or features, while it's always great to work on new stuff, there's also serious growth into improving something that currently works.

Personal experience on preferential treatment? it worked for me where if you try your best that every boring thing you touch turns into gold, you can make a new 'market'.

Example: slowly refactor some boring internal backend services, take 30 mins to sketch a few wireframes and show it around of what it could be to fellow users/officemates. It gets enough eyeballs that it turns into something exciting that other engineers would want to work on too. Management decides if it's worth the time or not, the key to win their approval is if the refactor/re-architecture/development is small enough to solve a very painful process point (ex: accounting needs data from different databases, solving a very buggy scenario from a current product currently solved by shoehorning manual data entries in some backend, etc.).

If you don't get approval, it's okay, you've refactored something crucial and your other officemates have definitely seen your worth. Just keep repeating it.

If not, my maker soul asks: maybe there should be one? Maybe I should build one? Would you consider using this kind of service in your applications if one exists? Why not?

To answer your "maybe there should be one?" question. What you're describing sounds like this: https://flatfile.io/. It was shared here 2 months ago.

Though to answer your original question:

How do you handle Excel import/exports in your apps

One way we go about that is: whenever someone uploads a file, create some sort of UploadRequest record which contains the filepath in S3/Azure/GCS/etc. Then the actual parsing and validation is spun off in a worker process. That way the web process isn't locked and we can pub progress ((processed_rows/row_count).percentage) on authorized subs. If that worker process ends, update the UploadRequest record status and dump the array of good_rows/error_rows in some column for that record. Users see that the status for that UploadRequest is updated, then they can review the UploadRequest errors. If there are errors, they download the uploaded file, fix that and re-upload again. At the start you can also provide a template to "gate" your upload, if it doesn't match your template you blow up UploadRequest with the proper error. If all is good, they click "Process" or something, which actually inserts the rows or does whatever.

Again, that’s just one way.

If bizdev asks to make a feature that allows fixing those rows in your app without leaving the browser, we find that it slowly feature creeps into Google Sheets territory, which is a BIG undertaking and a separate feature on it’s own. It's a nice experience to do in-app editing but we try to see if most of our Excel uploaders would prefer to go back to Excel for editing. Sometimes we find that they’ll prefer going back to Excel because they’ll use the same excel sheet for other purposes in their process (send that Excel as an email to another department, use that and aggregate it as a separate report, etc.).

But really, the hardest part in Excel uploads isn't server resources, progress, file encoding, or timeouts, it's the validation. There are different levels of validation: from presence checks, formatting, type-checking to running a row or a cell against business logic, 3rd-party API calls or records in your database. This is where most User errors arise, because you'd have to educate them on what values to put if you're referencing something in your business logic (special abbreviated codes, special combination of codes, date formats, etc.).

What goes into building a international payments service like Paypal?

A LOT of bizdev and treasury work, a.k.a. doing things that's hard to scale. Let's take for example: paying out USD to NGN or IDR.

To be able to pay out in Nigeria/Indonesia in a reasonable time, you'd have to buy a lot NGN/IDR and keep that money in a bank account somewhere. You can't expect to keep wiring out USD to Nigeria because if you do, you're at the mercy of Wire Transfers and fees, it wouldn't be sustainable.

Now depending on the payout, what if they wanted to pay out on a different bank? You have to maintain balance on that different bank too. The money stuck in a country is called "float". If you're lucky, their banks are interconnected and you transfer easily, but if not, you're going to have a harder time.

That's why there's always a "3-5 banking days on withdrawal", it's not because of wiring out your actual cash, companies like Paypal are trying to manage their "float".

Here's what actually happens when someone issues a NGN Withdrawal on your app: depending on the bank on the said country, if they have online banking, you'll have to actually login on your bank account and transfer manually. Believe me, there are only a handful of banks that has Transfer APIs. For some, to even access them, you'd have to be licensed, regulated and have a good relationship.

What if the NGN withdrawal on your app was a cash pickup location? You'd be pressed to also maintain a relationship or talk with local payout providers. Not every popular bank or cash pickup company has an API. Sometimes you'll have to email them a spreadsheet of the "Withdrawals". They'll reply back and you'd have to update the "Withdrawal" status manually or build something that parses emails/CSV to update them.

Now you might be wondering 'I want to lessen stuck capital so that I can offer lower fees'. Depending on the country; you'd have to look for local providers called "Aggregators". These guys can be remittance, money transfer companies that handle local payouts for you. Bonus points: they're usually tech savvy and might provide an API. You maintain balance with them and they take care of the 'Last Mile' of paying out and are fully licensed (hopefully). They charge a fee, and depending on Paypal, they pass it unto you or bake it in with their margins. A side note USDNGN has a black market rate that's way better than the banks, maintaining balance with a bank might be less competitive vs finding an aggregator that can offer you USDNGN black market rates.

That's the basic gist for the treasury work. Legal work mainly is to actually open a bank account and keeping in line with a country's AMLA and KYC regulations are another cost. Otherwise they'll shutdown your bank accounts. Depending on the speed/red-tape of the government processes, you'd have to bake in legal fees and months of back and forth with government agencies.

I have just described Withdrawals. I haven't even begun to describe the hardship of "Deposits", because you're actually in-line with being a quasi-bank, which has another set of licenses, permits and fees.

This is just for 1 country. Every country has it's own quirks, what you did for Nigeria cannot be replicated to say, paying out in KRW or IDR. They will have different licenses, legal fees, aggregators and banks, cash pickups, bank account limits/thresholds, that you'll have to sort and scope out. Not to mention the amount of local competition. You'll also have to keep tabs of changes in regulation, national holidays or changes in a bank/aggregator's policies.

Hopefully this outlines why Paypal cannot be dethroned easily. Stripe is getting there, but otherwise you'd have to embed yourself and have enough float in 100+ countries to even match them or Western Union.

Source: I work as a senior engineer at a remittance startup.

A Web UI where you can click a button that says "Launch VM" given CPU/RAM/Disk requirements, after a few minutes it returns to you SSH credentials.

Don't use cloud services. Literally, spin up a VirtualBox VM from where the web server is also hosted. Bonus points if you can spin up a VM from another web server.

The best experiences I can remember were when I was building games prototypes in XNA. I was only using the basics of the framework and writing a lot of the engine myself.

This happens to me as well, it's easy to keep churning out code when it's coming from my current bag of knowledge. My flow gets wrecked when I try to improve my code, because I have to stop writing the way I'm currently writing things the way I want to. When I mean "improve" code, it has to attain a certain metric and would usually entail giving benefits to other people working on the same codebase. Do I want the code to be more readable? more performant? more modular? more abstracted? would it depend-on/use another library?

What type of work do you do that regularly gets you in this state?

I find that I go back to a stop-start fashion of working when I don't know have a list of small wins I need to do to finish a big feature or "improving" code. Without that list, it leads me to procrastination.

So the first type of work I do? I bust out my pen and I get a piece of paper. Then I write down a small checklist of classes/methods I need to write, or small things I need to research (with a timebox).

I applied for a Rails Engineer job. Day 1, my team lead insisted on Grails. After 6 months, team leads stopped Product Development, and the next few months consisted of me being inside datacenters installing Hadoop clusters on baremetal. Funny thing is; I did that to myself, since I never complained and just took it in.

Almost 2 years in, never touched rails code, lots of ansible playbooks, dockerfiles, random ruby scripts, several company trips to Japan/US; it seems that I became the de-facto Big Data engineer on the company. Many would think it was something I liked. But I didn't. Executives, managers and engineers in the company relied on me to solve what was "sold" to current enterprise customers about "Big Data" and "Machine Learning". The pressure sets in. I couldn't in my nature pose myself as an "expert data scientist" and "big data guy" when I have 0 experience with ML, Python, Spark and Statistics.

I resigned. I thought the reason why I felt stressed because I was alone in this Big Data thing. Boy, I was so wrong. They counter-offered and gave me a high position + a 5-person team, 3 statisticians and 2 system administrators. I never should have took that counter-offer. This time, the pressure is higher since I'm officially responsible for the entire Product line. I needed to catch up to a hyped-up ecosystem of frustrated customers whose only chant was 'your company told me my Hadoop platform could do "Big Data + Machine Learning + AI" where is it?'.

After 4 months of trying; getting me and everyone on the team into Datacamp + Python training seminars, while writing an MVP for a ML-product I thought of, while building product roadmaps, being on meetings, handling internal politics and current customer support. I resigned.

I guess the real reason was; I didn't want this in the first place. Even if I tried to embrace the work, the climb was too steep with amount of runway I had. Customers are expecting ML-based products, now. I couldn't live up to the standards of a Big Data Lead when I have 0 experience on anything Big Data, no mentors teaching me about the proper way to write ML products, let alone run a team.

1. Reading helps. I find that reading the "manual" of a tech stack helps even more. Reading it slowly brings the best results, and if all else fails, reading the source. Under time pressure, my previous tendencies were to "Stack Overflow" and keep pasting stuff until it works. For simpler problems that worked, but for complex problems it didn't. Reading has helped a lot.

2. You can solve lots of problems and it might help. Over the course of time, my problem-solving skills improved slightly by the amount of problems I was solving. My problem-solving skills improved a lot just by polishing my problem-solving method. At the start of anything I take 15-30 minutes to write down the tasks I need to do and coordinate with others to check if it's the right set of things. I write, down to the classes, that I think I need to work on. For debugging, it's polishing the red-green-refactor cycle, for harder bugs I write the actual layers I need to peel (os/db/language version? database layer all good? weird logs? check disk? check I/O? network? skim through mailing lists? iperf? database? etc.).

ORM's are nice for majority of writes and simple reads based off of an object (a model).

It starts to hinder once there's a requirement for complex reports. I find, that's where the distatse of ORMs in an organization starts.

The other way to deal with majority of these complex reports is to create a separate OLAP table (model) to write/update too, and pull aggregates from there. But that's treading on a thin line of over-engineering.

ORM's are supposed to be used for Objects. If a report isn't a well-defined object/model, then it's going to fight against an ORM.

I do a simple version of a balanced scorecard:

1) Financial/Stakeholders - Are we raking in revenue? What type of revenue (high-touch, low-touch. high-volume/low-margin or low-volume/high-margin)? Are we consistently making this or is it totally dependent on the connections of 1-2 people? Can it be recreated? A bad sign is if people are being shifted to different projects all the time without one being totally completed/closed.

2) Customer/External Relationships - #1 is dependent on this. You can't make money with people giving you money. Do we have sufficient customers/market to provide the type of revenue needed? Do customers like us? What's the market feedback? A bad sign is if sales is overcommitting through the teeth about the products/services just to get them onboard.

3) Activities/Internal processes - #2 is dependent on this. You cant continually create things to sell and build customer relationships without a proper cycle of operations. Do we have processes? Does the process last long enough to get feedback? Or are the activities fickle and do not have solid implementations? A fishy sign is if there seems to be a totally new sales/engineering process every month, or isn't implemented rigidly and the org chart changes every 2 quarters.

4) Learning and growth (People-aspect) - Most important. #1, #2, #3 is dependent on this. You can't have processes/services/products without people. Based on the product/value that the company is providing to customers, are they valuing the people that creates this value? (training, leadership roles, ownership of product/services, etc.). Is there career growth for people that create this value? A fishy example would be: leadership positions in a product-based tech startup where there isn't at least one person with a history of software-engineering/operations and is instead filled with a group of salesmen. That startup would probably best be a consulting business, since the way things would be led hampers any kind of effort in building an effective product development pipeline/operation. Another bad sign for that type of startup is when key staff engineers are leaving, their positions are left empty and more managers are hired instead.

Trying my hand on a small elixir-based livestreaming video broadcast server using WebRTC. Broadcasters and Audience would be in react-native. Dunno if it would work though.

It depends on the type of development work you'll be working in. The main role of a Solutions Engineer is to translate marketing vision into technical specs. Take note on the word "vision", it means the customer will have high expectations because usually marketing/sales will present your product like it can do everything. Solutions Engineers mainly deal with high-touch sales, only means one thing: large enterprise customers.

If the customers you'll be handling would be up in AWS/Google, it's good, but if they have on-premise, that means you'll really have to know your stuff about the following:

- Feature Lists - translating what the product does into a feature list that describes perfectly what the customers are looking for. Makes it easier for them to explain to the board so they can get budget and approach finance and procurement.

- Active Directory or Auth0 integrations

- Network - from DNS/dnsmasq to iptables

- VA stuff - meeting generic hardening requirements and VA scans, java key stores, SSL certificates/ciphers and ton of Linux/Unix or Powershell.

- Linux/Unix - NTP, mail servers if need be, proxying using nginx/apache, user access, etc.

- Architecture - explaining the entire product in high-level and how components integrate with a customers current infrastructure

- Benchmarking - customers will ask apples to apples comparisons with other vendors, and they'll stick by your numbers.

- Appliance/Infrastructure sizing - you'll probably take part by this. Certain customers will definitely ask data growth and network growth as well. They need this to line up corporate budget.

and a lot more

So being a web developer is just a piece of the pie. Full stack is a must.