Kolejna zmiana pracy. Filtrowanie potencjalnie słabych ogłoszeń.

Kolejna zmiana pracy. Filtrowanie potencjalnie słabych ogłoszeń.
AI
  • Rejestracja:prawie 10 lat
  • Ostatnio:około 3 lata
  • Postów:375
1

Jakiś czas temu zacząłem nową pracę - na rozmowie wyszedłem w miarę dobrze, ja byłem zadowolony, rekruterzy też. Dowiedziałem się, że mają jakiś tool który w jakimś stopniu zrzuca odpowiedzialność za biznes z programistów. Przyjechałem do biura. Po trzech dniach dostałem dostęp do kodu i jakieś zadanie polegające na wyczyszczeniu czegoś w Storze. Myślałem sobie, no ok - wygląda na proste. Odpalam kod, potem debuggera żeby namierzyć błąd - znalazłem. Zorientowałem się od razu jak wygląda kod i, że nie da się tego zrobić w miarę fajny sposób bez gruntownego refactoru (dość duża część aplikacji z tego korzystała + przez ten tool za bardzo nie można było ruszać miejsca w którym ten błąd był). W międzyczasie znalazłem kilka innych niezbyt fajnych "pomysłów". Po tygodniu postanowiłem, że to nie ma sensu i, że Ja się będę tam męczył, nic nie napiszę i lepiej dla mnie i firmy, żebym poszukał czegoś nowego (na moje usprawiedliwienie mam to, że nie byłem pierwszy który odszedł po tygodniu). Ostatecznie umowę rozwiązaliśmy po 2 tygodniach.

Powysyłałem kilka CV, odezwałem się na LinkedInie do kilku HR'owców, w ciągu dwóch tygodni dostałem 2 propozycje pracy. Przyjąłem jedną z nich, wymagane było NgRx, Microfrontend, Angular 11+. Projekt - przepisanie aplikacji z AngularaJs do Angulara. Miesiąc już minął i widzę, że kolejny niezbyt fajny przypadek. Okazuje się, że dalej trzeba wspierać IE11, w projekcie panuje burdel (jeśli chodzi o kod), korzystanie z zewnętrznych komponentów jest praktycznie niemożliwe, a nawet jeśli by było - to problem jest taki, że i tak ich użyć nie można bo style się nie będą zgadzać w pozostałych miejscach aplikacji. Z Angulara to nawet z RouterModule nie można było korzystać bo AngularJS przeszkadzał (nie ja konfigurowałem routing, tutaj na zmiany raczej nie ma szans bo nikt nie wie jak to dobrze zrobić). Niby jest Typescript, a wygląda to jak zwykły JS bo w wielu miejscach nawet nie ma typu określonego. Zaczynam zadanie, próbuję przepisać jakiś komponent i kończy się tak jak zwykle, że się nie da bo brakuje komponentu. Myślałem nad stworzeniem osobnego modułu i projektu, gdzie byłyby trzymane takie komponenty, ale z tego co się dowiedziałem nie bardzo jest jak. Zacząłem przepisywać brakujący komponent, skończenie go zajmie mi z 3-4 dni, ale brakujących komponentów będzie dość dużo. Dodatkowo logikę + style trzeba pisać pod IE11 - co jest dość męczące. Jeszcze kilka innych dość utrudniających rzeczy by się znalazło.

Znowu myślę nad zmianą pracy / nauką jakiegoś nowego języka, tylko to już będzie drugie odejście w ciągu trzech miesięcy. Czy da się jakoś zminimalizować ryzyko natrafienia na takie firmy w przyszłości? Jeśli tak, to jak? Doświadczenia mam 2 lata, coś tam umiem - bo na 7 rozmów technicznych w ciągu tych 3 miesięcy, dostałem 5 propozycji pracy. Pierwszą pracę zmieniłem po 2 latach, tylko to był dość nowy projekt więc legacy kodu praktycznie nie było (jedyne minusy to potrzeba dostosowania się do wszystkiego i fatalne API), jak odchodziłem - wydaje mi się, że wszystko zostawiłem w dość dobrym stanie i dość dużo rzeczy przemyślałem i zautomatyzowałem, PO i inni programiści byli raczej zadowoleni.

edytowany 1x, ostatnio: Aisekai
KamilAdam
  • Rejestracja:ponad 6 lat
  • Ostatnio:5 dni
  • Lokalizacja:Silesia/Marki
  • Postów:5505
8

Zacząłem przepisywać brakujący komponent, skończenie go zajmie mi z 3-4 dni, ale brakujących komponentów będzie dość dużo.

Płacą ci od zrobionego zadania czy od samego robienia?

Pierwszą pracę zmieniłem po 2 latach, tylko to był dość nowy projekt więc legacy kodu praktycznie nie było

Eh, co frontendowcy tacy dalikatni. Wszyscy by chcieli pracować w greenfieldach. Z drugiej strony jak ma się język bez typowania to nic dziwnego żenikt nie chce dotykać legacy.

Znowu myślę (...) nauką jakiegoś nowego języka

I to jest bardzo dobry pomysł. Tylko tym razem wybierz język który ma typy


Mama called me disappointment, Papa called me fat
Każdego eksperta można zastąpić backendowcem który ma się douczyć po godzinach. Tak zostałem ekspertem AI, Neo4j i Nest.js . Przez mianowanie
Zobacz pozostałe 2 komentarze
szatkus
Tak samo jak możesz napisać Object albo * void
KamilAdam
Czyli to jednak nie jest zepsucie samego języka a jednak zepsucie programistów. No bo jednak programiści Javy nie piszą wszędzie Object. Język można poprawić, ale poprawić ludzi jest o wiele trudniej :(
AL
@KamilAdam: w C można pisać też źle i dobrze. Raczej pisze się źle, bo krótkoterminowo tak bywa prościej.
szatkus
@KamilAdam: tak samo użycie any w TS oznacza karę śmierci na code review.
nowy_kret_2
problem z ts'em i angularem jest taki ze zazwyczaj pisza w tym ludzie czesto wywodzacy sie z js'a (co jest naturalne), nieprzyzwyczajeni do typow, a pozniej historie jak powyzej
99xmarcin
  • Rejestracja:prawie 5 lat
  • Ostatnio:5 miesięcy
  • Postów:2420
1

Byłem kiedyś w podobnym miejscu jak Ty teraz. Generalnie było już na tym forum sporo wątków o tym jak znaleźć dobrą firmę i jak na rozmowie rekrutacyjnej "odpytywać" drugą stronę.

Ja mogę Ci poradzić tylko jedno idź do firmy gdzie jest dość wysoki próg wejścia i moco algorytmiczna rekrutacja, co jak co ale w takich firmach zawsze panuje w kodzie porządek.

Druga droga to szukanie pracy przez znajomych, ale musisz gościom ufać bo 10k (ba teraz to i 15k lub 20k) za polecenie może niejednego "przyjaciela" nakłonić do utęczowienia rzeczywistości. Trust but verify lub nasze PRLowski Kontrola podstawą zaufania :D Niech Ci pokaże kod, i jak będzie OK to aplikuj.

PS. I na koniec nie można mieć wszystkiego, ładny kod to często mniejsza kasa, łajno kod to często lepszy zarobek, tak samo jak SharePoint :P Zawsze możesz to traktować tylko w kategoriach pracy, tak jak np. zbieranie ziemniaków. Trzeba zebrać i koniec, a po 8h możesz robić co chcesz...


Holy sh*t, with every month serenityos.org gets better & better...
edytowany 1x, ostatnio: 99xmarcin
Shalom
  • Rejestracja:około 21 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:Space: the final frontier
  • Postów:26433
8
  1. Sorry Winnetou, ale 90% softu to rozwijanie czegoś co istnieje a nie greenfield i nowy kod
  2. Często ludzie narzekają że projekt słaby, ale jak mają sami od zera coś zaprojektować to nagle okazuje się że w sumie nie wiedzą jak to zrobić żeby miało ręce i nogi
  3. Jak projekt słaby, to trzeba zakasać rękawy i naprawiać.
  4. Zamiast wysyłać CV do losowych miejsc, może zastanów się gdzie chciałbyś pracować? i właśnie tam aplikuj?

"Nie brookliński most, ale przemienić w jasny, nowy dzień najsmutniejszą noc - to jest dopiero coś!"
99xmarcin
Ale tutaj masz błędne koło: żeby nauczyć się projektować to trzeba projektować, nie każdy robi to w czasie wolnym jako open source -> ludzie nie umieją projektować. Niestety projektowanie i potem utrzymywanie własnego kodu to jedyna możliwość żeby zobaczyć co działa a co nie.
superdurszlak
@0xmarcin: to samo miałem napisać
AL
wszystko jest dobrze tak długo jak góra pozwala robić refaktoring zamiast "nap...laj ficzera i kij z jakością i testami". Ile razy się spotkałem z tym, że "ifa masz dodać a nie się mądrzyć, i co z tego że testy dodałeś" to nie zliczę. Powodzenia z dobrymi nawykami i nauką "projektowania" w takich okolicznościach.
PI
@Shalom: Punkty 1. i 2. Zgadzam się w 100000%
Shalom
Moim zdaniem wystarczy brać udział w projekcie gdzie ktoś projektuje i też powoli nauczymy się jak się to robi. Reszta przychodzi z doświadczeniem bo widzisz co i kiedy działa a co nie.
PO
  • Rejestracja:około 6 lat
  • Ostatnio:10 miesięcy
  • Postów:11
6

Ostatnio byłem w podobnej sytuacji… Przyszedłem do firmy, w której kod frontowy jest na bardzo słabym poziomie i początkowo myślałem, żeby wysyłać CV, ale… doszedłem do wniosku, że warto spróbować naprostować, to co jest źle, co prawda mam trochę więcej doświadczenia niż ty i będzie mi pewne zmiany łatwiej przeprocesować, ale jeśli spróbujesz to pokażesz się z solidnej strony i na pewno pozytywnie to wpłynie na Twoje wynagrodzenie / stanowisko.

Pamiętaj, że idealnie nigdy nie będzie, ale małymi kroczkami możesz swój idealny świat wprowadzać odpowiednio argumentując zmiany.

No i na IE11 nie narzekaj aż tak ;) Safari też jest uciążliwe w stylowaniu, a tego tym bardziej nie wykluczysz.

AL
  • Rejestracja:prawie 11 lat
  • Ostatnio:prawie 3 lata
  • Postów:1493
0

ale jeśli spróbujesz to pokażesz się z solidnej strony i na pewno pozytywnie to wpłynie na Twoje wynagrodzenie / stanowisko.

Niekoniecznie, ale dopóki nie spróbujesz to się nie dowiesz.

stivens
  • Rejestracja:ponad 8 lat
  • Ostatnio:około 5 godzin
2

Moze wroc do pierwszej pracy


λλλ
SI
  • Rejestracja:ponad 6 lat
  • Ostatnio:27 minut
  • Postów:296
0

Aplikuj do ciekawszych i wiekszych firm gdzie w razie czego możesz po prostu zmienić dział?

Zobacz pozostałe 5 komentarzy
stivens
@Shalom: Java go chyba nie usatysfakcjonujesz. :P Btw. caly czas zapraszasz ludzi czy to do CERNu czy ESO - jakie sa realne szanse? Bo chyba male
stivens
@KamilAdam: ktora masz na mysli?
Shalom
@stivens: mi się udało więc nie może być tak ciężko
ToTomki
Mnie się udało zmienić dział i zespół. Dalej było słabo, ale dzięki temu udało mnie się wypchnąć w fajnym kierunku i nie żałuję. Warto było. I to w dużym jak na Polskę banku.
CW
  • Rejestracja:około 9 lat
  • Ostatnio:ponad 2 lata
  • Postów:251
5

Ktoś już tu kiedyś napisał, że każdy nowy projekt w jego firmie zaczyna się z obietnicą "ładnego kodu", nowych narzędzi i technologii, a później przychodzi proza życia, upływające terminy, łatanie w biegu, nieudokumentowane poprawki i stare sprawdzone narzędzia. Takie jest życie i pewnie 80% projektów tak wygląda.

edytowany 2x, ostatnio: cw
ledi12
  • Rejestracja:ponad 5 lat
  • Ostatnio:26 dni
  • Lokalizacja:Wrocław
2

Praca jest przede wszystkim od zarabiania. Nie ma idealnego projektu, zwyczajnie trzeba się nauczyć w takim funkcjonować. Jeśli coś nie gra to spróbować to zmienić, ulepszyć.. Ogólnie podjąc próbę działania a nie od razu uciekać. Jak dla mnie problem leży w Twoim podejściu do tematu stąd tak częste zmiany. Źle to będzie wyglądać w cv :P


Robię http response status cody w martwych ciągach
BluzaWczolg
BluzaWczolg
  • Rejestracja:ponad 6 lat
  • Ostatnio:ponad 3 lata
  • Postów:530
0

@Shalom:

Sorry Winnetou, ale 90% softu to rozwijanie czegoś co istnieje a nie greenfield i nowy kod

Tak, ale pytanie czy to co istnieje ma 5,10, czy 30 lat. Nowy kod to pojęcie subiektywne.

Jak projekt słaby, to trzeba zakasać rękawy i naprawiać.

Nic nie trzeba.

Zamiast wysyłać CV do losowych miejsc, może zastanów się gdzie chciałbyś pracować? i właśnie tam aplikuj?

Co do samej jakości firmy i projektu to nie jest IMO zawsze takie łatwe, bo najlepiej mieć opinie od ogarniętych, uczciwych znajomych, których czasem brak w każdej firmie, a na gowork itp. ciężko zweryfikować, jaki jest dokładnie obraz, to są opinie od anonimów.

@Aisekai

Czy da się jakoś zminimalizować ryzyko natrafienia na takie firmy w przyszłości?

Rozumiem, że poprzez **takie firmy **, masz na myśli takie gdzie jest burdel w kodzie i technologie które Ci nie pasują? Na następnych rozmowach spróbuj wybadać :

  1. W jaki sposób dbają/dbali o jakość kodu.
  2. Jakie technologie zastaniesz w kodzie i co konkretnie będziesz robił. To może być co innego niż to co napisali w ogłoszeniu w "wymagane/nice to have".

W tym dziale znajdują się wątki z pytaniami do potencjalnego pracodawcy, myślę że warto je przejrzeć jak już się ma pierwsze doświadczenie.

IMO samo ogłoszenie jest ciężko odfiltrować w 100% bez zaangażowania się w proces rekrutacyjny, nie wszystkie informacje podaje HR na pierwszej rozmowie, tylko trzeba popytać technicznego po rozmowie konkretniejszej.

Inna sprawa, to to, że raczej nie ma idealnej firmy/projektu. Z poprzedniej odszedłeś z jakiegoś powodu.


Nie czarodziejska tylko magiczna. I nie fujarka tylko flet. Magiczna flet.
edytowany 4x, ostatnio: BluzaWczolg
Zobacz pozostały 1 komentarz
BluzaWczolg
BluzaWczolg
Różnice widzę 2: nowy projekt można łatwiej ogarnąć, bo jest mniejszy. Nowy projekt raczej nie będzie mieć technologii które okazały się nietrafione. Np. pamiętam że jeżeli chodzi o Javę, to znajomi klęli na utrzymywanie JSF.
DR
@BluzaWczolg: co wcale nie oznacza że nowy projekt nie będzie mieć technologii które nie okażą się nietrafione - kilka lat temu zespół obok wyklinał na niedojrzałość Ktora którego sobie wybrali bo jak w kotlinie piszą to już nie wypada pisać w springu
Shalom
Nowy nie znaczy mały ;) a nowa technologia może być tym bardziej chybiona. W starym projekcie mogli taką już wymienić na coś lepszego.
Miang
@devRandom: +1
BluzaWczolg
BluzaWczolg
@devRandom Nie wiem, czy mówimy o tym samym, mi chodziło o co innego, niż dobór odpowiedniej technologii do danego projektu i jego wymagań, choć to też jest ważne. Po prostu na pewne technologie klęli wszyscy i potem były zastępowane czymś wygodniejszym.
TS
  • Rejestracja:ponad 5 lat
  • Ostatnio:36 minut
  • Postów:853
12

screenshot-20210808175616.png

edytowany 1x, ostatnio: cerrato
.andy
Piękne ;)
P1
  • Rejestracja:ponad 3 lata
  • Ostatnio:ponad 3 lata
  • Postów:22
1

Praktycznie 99% ogłoszeń jest słabych i to nie z powodu stanu kodu jaki uzyskasz do utrzymania, ale z powodu: słabych umów, zespołu i zarządzania.

Jeśli firma nie jest nastawiona na sukces to dla mnie z miejsca przegrała. Z tego co widzę największym problemem firmy jest ona sama. Typowa firma to taki tłuścioch, który od czasu do czasu musi wbiec na górkę. Niestety ponosi przy tym ogromny trud i to tylko na własne życzenie (brak zaangażowania/kondycji, niezdrowy rozmiar).

A jeśli firma unika górek, jeśli nie napiera do przodu, jeśli woli o tym wyłącznie gadać to będzie się tylko cofać, przepalać zasoby, unikać problemów jakie rzeczywiście czekają na rozwiązanie.

Jeśli od środka, kierownik zespołu nic konkretnego sobą nie reprezentuje, nie jest dla mnie przykładem lub co gorsza jest tylko poganiaczem to klapa. W takim miejscu stracisz wyłącznie czas, entuzjazm i chęć do rozwoju, bycia lepszym. Wtedy włącza się hibernacja, chęć odczekania do 17, a potem nawet nie próbujesz nawet zrozumieć co się stało, bo to nie Twój problem.

Po paru próbach mnie to już nie dziwi, finalnie:

  • Oprogramowanie stanowi środek do poszerzenia istniejących wpływów lub ograniczenia wydatków, samo w sobie oprogramownie nie jest źródłem kasy, to bardziej automatyzacją/optymalizacją już wcześniej podjętych działań. Jesteśmy wydatkiem bardziej z konieczności niż z zamiarem na osiąganie wielkich rzeczy. Generujemy koszty i niczym się nie różnimy od księgowych czy grafików :-(
  • Firmy utrzymujące soft wolą mierzyć jak słabe i przewidywalne są ich rezultaty zamiast odpowiadać na to co ma znaczenie.
  • Pracownicy chcą mieć święty spokój, oni przychodzą do pracy w głównej mierze odpocząć i odklikać swoje. Zasuwać to może ten kto nie wierzy w siebie, a im bardziej kompetenty gość tym bardziej szanuje swój czas, tym większy dystans ma do tego co dzieje się w firmie. Siłą rzeczy ciężej jest się uczyć od lepszych ludzi skoro oni przez większą część pracy robią uniki lub odpowiadają na problemy, które bardziej im leżą.
  • Brak ryzyka i czucia efektów. Sukces firmy nie jest sukcesem pracownika, podobnie jak porażka. Koder nie ma odniesienia, które mogłoby mu powiedzieć czy to co robi ma jakąkolwiek wartość. W efekcie te ambitniejsze dyskusje programistyczne odnoszą się do tego co jest bardziej poprawne niż to co ma większe znacznie, czego efektem jest to, że komplikujemy zamiast upraszczać.
  • Będąc w środku takiej firmy czuję jakbym na start otrzymał (w tych ciut lepszych firmach) wygrawerowaną na łopacie nazwę technologi, jakby to samo z siebie miało sprawić, że będę kopał głębiej, dalej i dłużej. Inny typ firmy jaki spotkałem to coś na kształt rutyny niczym barista, gdzie co dzień w sumie serwuje to samo tyle, że w innej kolejności.
edytowany 2x, ostatnio: pprog123
Zobacz pozostałe 36 komentarzy
stivens
Po prostu wyraziles subiektywna opinie, ktora nie musi byc respektowana w ogolnosci
P1
Aha, ciekawe zajawisko, kto by mógł się tego spodziewać. Zwłaszcza tutaj, nie? :D
Miang
@pprog123: jakie zwolnienia , gdzie pisałam o zwolnieniach (po co ja karmie Trolla to nie wiem)
Kliknij, aby dodać treść...

Pomoc 1.18.8

Typografia

Edytor obsługuje składnie Markdown, w której pojedynczy akcent *kursywa* oraz _kursywa_ to pochylenie. Z kolei podwójny akcent **pogrubienie** oraz __pogrubienie__ to pogrubienie. Dodanie znaczników ~~strike~~ to przekreślenie.

Możesz dodać formatowanie komendami , , oraz .

Ponieważ dekoracja podkreślenia jest przeznaczona na linki, markdown nie zawiera specjalnej składni dla podkreślenia. Dlatego by dodać podkreślenie, użyj <u>underline</u>.

Komendy formatujące reagują na skróty klawiszowe: Ctrl+B, Ctrl+I, Ctrl+U oraz Ctrl+S.

Linki

By dodać link w edytorze użyj komendy lub użyj składni [title](link). URL umieszczony w linku lub nawet URL umieszczony bezpośrednio w tekście będzie aktywny i klikalny.

Jeżeli chcesz, możesz samodzielnie dodać link: <a href="link">title</a>.

Wewnętrzne odnośniki

Możesz umieścić odnośnik do wewnętrznej podstrony, używając następującej składni: [[Delphi/Kompendium]] lub [[Delphi/Kompendium|kliknij, aby przejść do kompendium]]. Odnośniki mogą prowadzić do Forum 4programmers.net lub np. do Kompendium.

Wspomnienia użytkowników

By wspomnieć użytkownika forum, wpisz w formularzu znak @. Zobaczysz okienko samouzupełniające nazwy użytkowników. Samouzupełnienie dobierze odpowiedni format wspomnienia, zależnie od tego czy w nazwie użytkownika znajduje się spacja.

Znaczniki HTML

Dozwolone jest używanie niektórych znaczników HTML: <a>, <b>, <i>, <kbd>, <del>, <strong>, <dfn>, <pre>, <blockquote>, <hr/>, <sub>, <sup> oraz <img/>.

Skróty klawiszowe

Dodaj kombinację klawiszy komendą notacji klawiszy lub skrótem klawiszowym Alt+K.

Reprezentuj kombinacje klawiszowe używając taga <kbd>. Oddziel od siebie klawisze znakiem plus, np <kbd>Alt+Tab</kbd>.

Indeks górny oraz dolny

Przykład: wpisując H<sub>2</sub>O i m<sup>2</sup> otrzymasz: H2O i m2.

Składnia Tex

By precyzyjnie wyrazić działanie matematyczne, użyj składni Tex.

<tex>arcctg(x) = argtan(\frac{1}{x}) = arcsin(\frac{1}{\sqrt{1+x^2}})</tex>

Kod źródłowy

Krótkie fragmenty kodu

Wszelkie jednolinijkowe instrukcje języka programowania powinny być zawarte pomiędzy obróconymi apostrofami: `kod instrukcji` lub ``console.log(`string`);``.

Kod wielolinijkowy

Dodaj fragment kodu komendą . Fragmenty kodu zajmujące całą lub więcej linijek powinny być umieszczone w wielolinijkowym fragmencie kodu. Znaczniki ``` lub ~~~ umożliwiają kolorowanie różnych języków programowania. Możemy nadać nazwę języka programowania używając auto-uzupełnienia, kod został pokolorowany używając konkretnych ustawień kolorowania składni:

```javascript
document.write('Hello World');
```

Możesz zaznaczyć również już wklejony kod w edytorze, i użyć komendy  by zamienić go w kod. Użyj kombinacji Ctrl+`, by dodać fragment kodu bez oznaczników języka.

Tabelki

Dodaj przykładową tabelkę używając komendy . Przykładowa tabelka składa się z dwóch kolumn, nagłówka i jednego wiersza.

Wygeneruj tabelkę na podstawie szablonu. Oddziel komórki separatorem ; lub |, a następnie zaznacz szablonu.

nazwisko;dziedzina;odkrycie
Pitagoras;mathematics;Pythagorean Theorem
Albert Einstein;physics;General Relativity
Marie Curie, Pierre Curie;chemistry;Radium, Polonium

Użyj komendy by zamienić zaznaczony szablon na tabelkę Markdown.

Lista uporządkowana i nieuporządkowana

Możliwe jest tworzenie listy numerowanych oraz wypunktowanych. Wystarczy, że pierwszym znakiem linii będzie * lub - dla listy nieuporządkowanej oraz 1. dla listy uporządkowanej.

Użyj komendy by dodać listę uporządkowaną.

1. Lista numerowana
2. Lista numerowana

Użyj komendy by dodać listę nieuporządkowaną.

* Lista wypunktowana
* Lista wypunktowana
** Lista wypunktowana (drugi poziom)

Składnia Markdown

Edytor obsługuje składnię Markdown, która składa się ze znaków specjalnych. Dostępne komendy, jak formatowanie , dodanie tabelki lub fragmentu kodu są w pewnym sensie świadome otaczającej jej składni, i postarają się unikać uszkodzenia jej.

Dla przykładu, używając tylko dostępnych komend, nie możemy dodać formatowania pogrubienia do kodu wielolinijkowego, albo dodać listy do tabelki - mogłoby to doprowadzić do uszkodzenia składni.

W pewnych odosobnionych przypadkach brak nowej linii przed elementami markdown również mógłby uszkodzić składnie, dlatego edytor dodaje brakujące nowe linie. Dla przykładu, dodanie formatowania pochylenia zaraz po tabelce, mogłoby zostać błędne zinterpretowane, więc edytor doda oddzielającą nową linię pomiędzy tabelką, a pochyleniem.

Skróty klawiszowe

Skróty formatujące, kiedy w edytorze znajduje się pojedynczy kursor, wstawiają sformatowany tekst przykładowy. Jeśli w edytorze znajduje się zaznaczenie (słowo, linijka, paragraf), wtedy zaznaczenie zostaje sformatowane.

  • Ctrl+B - dodaj pogrubienie lub pogrub zaznaczenie
  • Ctrl+I - dodaj pochylenie lub pochyl zaznaczenie
  • Ctrl+U - dodaj podkreślenie lub podkreśl zaznaczenie
  • Ctrl+S - dodaj przekreślenie lub przekreśl zaznaczenie

Notacja Klawiszy

  • Alt+K - dodaj notację klawiszy

Fragment kodu bez oznacznika

  • Alt+C - dodaj pusty fragment kodu

Skróty operujące na kodzie i linijkach:

  • Alt+L - zaznaczenie całej linii
  • Alt+, Alt+ - przeniesienie linijki w której znajduje się kursor w górę/dół.
  • Tab/⌘+] - dodaj wcięcie (wcięcie w prawo)
  • Shit+Tab/⌘+[ - usunięcie wcięcia (wycięcie w lewo)

Dodawanie postów:

  • Ctrl+Enter - dodaj post
  • ⌘+Enter - dodaj post (MacOS)