I downloaded this and opened up a React based project that uses functions and not classes. I'm not seeing the sideways facing arrows to show the call stack of the function I'm looking at and have my cursor in - the functions that call the function I'm looking at and the functions that reference the function I'm looking at.
It seems the sideways arrows in the demo only appear for class based methods and not plain functions :(
Overall I love the idea and have wanted a graph visualization of a codebase showing every function call, who calls it, and who it is called by which this seems to do but for classes. Hope to see this working for functions as well soon! Great work.
Sorry for the frustrating behavior. It should actually work for plain functions and I just tested with a TSX component we use. I think something went wrong here.
Are you using JSX components? I'll try to repro this on my end.
I'm using a mix of TSX/JSX/TS/JS. I wasn't seeing it working for any of the functions (component or plain JS) I have unfortunately. Will keep an eye out for any updates you make to resolve this!
Awesome project and great work on it! Congrats on the launch :)
Modal editors like vim and helix have modes[0] that allow for different operations.
Vim has
- normal mode which allows you to enter commands to manipulate text rather than just type characters in the file
- insert mode which allows you to enter text into a file
- replace mode which allows you to replace text
and a few others.
Most editors like vscode, sublime etc only have a single mode that they are always in IE insert mode. Modal editors have additional modes that allow for additional capabilities.
Stock buy backs are simply a tax efficient return to investors that are an alternative to dividends.
They are tax efficient since dividends are taxed before they can be reinvested (back into the same stock or any other investment) whereas stock buy backs allow the investor, rather than the company, to decide when to incur the taxes which would be incurred by selling the appreciated shares.
Financially they are equivalent.
The only real argument against either buy backs or dividends concerns if the company is better off pursing this return of investment to shareholders or investing the money back into the business to pursue growth. Finding the balance between these two is critical for every company.
The other difference is that with a buy back your return is reinvested in the stock. The company could make a mis-step tomorrow and make it go away. With a dividend the return is liquid and risk free. If you are re-investing your dividends in a taxable account you should prefer buy backs instead. If you are hoping to use your returns for cashflow you will prefer companies that issue dividends. If you're investing in a tax-deferred or tax-free account then it shouldn't matter.
In the US in 2024 you can collect up to $94k in qualified dividends and owe no federal taxes.
Yes, the expected dividends, however growth in stock prices are due to /unexpected/ risk adjusted growth.
ISO options often have a 10 year period after vesting, it is unlikely to be predictable in pricing.
Also, the exercise amount has to be the current share price or higher or you pay gains on them.
Edit:
You see the same thing with unvested RSU’s if the company does not do something extra but not required.
Edit2:
The price you pay for the option on the open market accounts for it as best they can, but does not account for grants in ISO options and unvested RSU’s. Largely held by insiders. Hence the conspiracy theories.
I've loved books that have won lots of awards and recognition that I only read cause it was part of a curriculum, but it's perfectly reasonable to also not connect with some of them.
I read almost exclusively fantasy and have always loved reading since I was young. Fantasy series are often trilogies or more with some being over 10 books long.
You go on adventures, read about relationships, interpersonal problems, power, team work, individualism, religion, and so much more. While it's mostly what I read, it's not all, but it keeps me reading.
My team has done a lot of work to lean into the tool IE well defined issues, epics, tickets, t shirt sizing for pointing via 1, 3, 5, etc.
There is lots that can be improved for sure.
With this system, my team, in addition to any one else at the company, is able to click into our JIRA board and get a very high level to a very low level understanding of what we are working on.
This allows for very clear reporting structures and ensures our goals are on track with those of the company's. This also makes outcomes more measureable which is exceptionally helpful for reviews.
At the end of the year or halfway through I can go in and say: I worked on these 4 epics that are part of these two Issues which serve company goals A, B, and C. I completed x% of the tickets for each of these epics, led this entire other epic which was completed on time etc etc.
Where we run into issues is when there is a ticket that has to move between boards. The ideal situation is we just move the ticket from board to board as needed but based on the user they may or may not have permissions and have to open a new ticket linking it to the previous one. Not ideal but that's up to us to resolve to make sure the right people have the right permissions.
We ignore all the analytics IE burn down and friends. Those are useless.
I was on a team building tweet tiles[0][1] which required a cross platform UI system that would allow 3rd party developers to register a schema that would be used to render a custom UI under certain circumstances (usually by including a link in your post). We made it to beta, but never beyond given the internal turmoil.
We considered Adaptive Cards, but ultimately decided against it in favor of our own schema especially since we already had platform specific UI libraries.
Why?
Adaptive cards proved inflexible for uses not part of its core capabilities.
Adaptive cards doesn't allow for interactive elements IE charts or graphs with tool tips.
Adaptive cards doesn't appear to be well maintained or supported for ongoing future needs.
There were some other reasons but they are fuzzy a couple of years after the fact. This was one of the most fun projects I've worked on, I had to write a mini parser which is always a fun exercise, and I think it had massive potential. Would have been a very cool project to ship to prod fully but it wasn't meant to be.
The subreddit r/mintuit[0] has tons of posts and detail on all these alternatives and people's experiences with them with reviews and everything else you could want to know.
Dependency injection is 'just' passing an argument to a function or method.
Whether that happens via the constructor, some method, or a plain ol' function, its very simple.
But naming it dependency injection and ascribing terms like setter injection, or constructor injection or discussing dependency injection frameworks with complicated set up instructions, can make this very simple concept seem significantly more complex and difficult for junior and mid level engineers.
The flip side to these performance cycles is all the time in between in which often very little actionable feedback is provided to engineers which makes the mid year and end of year reviews so difficult.
Across 3 companies and 8 managers, I have yet to receive feedback that was productive in helping me understand what skills or track record is lacking and what is necessary to move up. Managers are (often) bad at providing actionable feedback let alone any feedback which leads to lots of blandness in 1:1s which translates to lots of blandness in mid year and end of year review cycles.
I try and rectify this by finding quantitative data: impact on revenue (very difficult though most of the time), MRs merged, GitHub activity, tickets closed, projects led, initiatives taken, demos presented etc but this only goes so far.
All this leads me to believe that at the end of the day promotions are decided by various levels of managers getting together with a few beers, deciding how many total promotions can take place due to budget, and going through a list of names while deciding based on their gut but of course this can't be admitted as the official process.
It is frustrating that unlike other careers IE finance, law, medicine etc where performance can be directly tied to revenue (investment returns, client income, patient income) we have yet to design a standard for measuring impact for many software engineering roles.
This isn't targeted at you directly however I have been on the other side of this. I've sometimes been too open with actionable feedback. What has bit me is that people say they want actionable feedback, but then get defensive or sometimes mildly hostile at any conceived criticism.
This led me to be much more careful with feedback and only give it if I know they can take it. If you think you are one of these people and you receive feedback, just ask questions.. don't dig in and defend yourself.
> medicine etc where performance can be directly tied to revenue (..., patient income)
What is "patient income?" How much money the MBAs in private equity that took over the hospital made by penny pinching and cutting corners in quality of care?
It seems the sideways arrows in the demo only appear for class based methods and not plain functions :(
Overall I love the idea and have wanted a graph visualization of a codebase showing every function call, who calls it, and who it is called by which this seems to do but for classes. Hope to see this working for functions as well soon! Great work.